Transaction exchange platform to determine secondary workflows for transaction object processing

ABSTRACT

Aspects described herein may relate to a transaction exchange platform using a streaming data platform (SDP) and microservices to process transactions in accordance with corresponding workflows. The transaction exchange platform may receive transactions from origination sources, which may be added to the SDP as transaction objects. Microservices on the transaction exchange platform may interact with the transaction objects based on configured workflows associated with the transactions. Further, the microservices may leverage machine-learning models to determine whether transaction objects may be more effectively processed using alternative or secondary workflows. Processing on the transaction exchange platform may facilitate clearing and settlement of transactions. Some aspects may provide for dynamic and flexible reconfiguration of workflows.

FIELD OF USE

Aspects of the disclosure relate generally to a transaction exchangeplatform. More specifically, aspects of the disclosure may provide fordynamic, reliable, and auditable processing of transactions through useof a streaming data platform.

BACKGROUND

Computer systems and applications have revolutionized the handling oftransactions and greatly accelerated clearing and settlement processes.Software solutions have been created to facilitate processing,validation, and approval of transactions. These systems serve tointerface transaction originators with clearing and settlementoperations, allowing transactions to flow between enterprises andfacilitating the movement of trillions of dollars per year. Yetregulations, security, and risk management processes have grownincreasingly important and detailed, thereby complicating the approvaland settlement of transactions.

Different transaction types may be subject to different approvalworkflows. Payment processing systems may be configured to perform therequired approval steps for each different transaction type. Yet suchpayment processing systems have become incredibly complex, monolithicsoftware services designed to accommodate and enforce the many aspectsof the process of reviewing and approving a transaction for settlement.Although sometimes divided into modules corresponding to differenttransactions, changes to single steps in a given transaction's approvalworkflow may require re-coding, re-compiling, and re-deploying largesoftware components. Additionally, problems with individual steps of theworkflows can grind the whole approval process to a halt.

Computing systems and applications are used to process a vast array oftransactions involved in clearing and settlement processes betweenenterprises. These computing devices and applications serve tofacilitate the efficient processing, validation, and approval oftransactions. For a variety of reasons some transactions may wind upbeing processed using workflows that are suboptimal, which may result inmissed deadlines, additional costs, and overall inefficiency in theclearing and settlement process. As a result there is a need for a wayto determine alternative workflows for existing transactions, therebyimproving the effectiveness with which the transactions are processed.

Additionally, as the result of various factors, the processing ofcertain transactions may be incomplete, stalled, or otherwiseunsuccessful. Such transactions may remain unattended for significantperiods of time, resulting in missed deadlines, late payment penalties,and overall inefficiency in the transaction process. In order to meetdeadlines, reduce late payment penalties, and improve the overalleffectiveness of the transaction process, there exists a need for a wayto determine secondary workflows to complete the processing oftransactions that have been unsuccessful.

Aspects described herein may address these and other shortcomingspresent in existing solutions.

SUMMARY

The following presents a simplified summary of various aspects describedherein. This summary is not an extensive overview, and is not intendedto identify key or critical elements or to delineate the scope of theclaims. The following summary merely presents some concepts in asimplified form as an introductory prelude to the more detaileddescription provided below.

Aspects described herein may relate to a transaction exchange platformthat uses a streaming data platform (SDP) and microservices to processtransactions in accordance with designated workflows associated with therespective transactions. The transaction exchange platform may receivetransactions from origination sources, which may be added to the SDP astransaction objects. Microservices on the transaction exchange platformmay interact with the transaction objects based on configured workflowsassociated with the transactions. Processing on the transaction exchangeplatform may facilitate clearing and settlement of transactions. Someaspects may provide for the use of classification microservices that areconfigured to classify transaction objects and determine alternativeworkflows that may more effectively process transaction objects. Theclassification microservices may leverage machine-learning models thatare configured to determine more effective workflows to process thetransaction objects. Other aspects may provide for the determination ofworkflows in which processing of a transaction objects was notsuccessfully completed and the subsequent determination of analternative workflow to successfully process the transaction object.

Aspects described herein may allow for automatic methods, systems,transaction exchange platforms, devices, and apparatuses to determinealternative workflows for transaction objects and may include the use ofmachine-learning models that are configured and/or trained to classifytransaction objects. More particularly, some aspects described hereinmay provide a computer-implemented method for processing transactions.The computer-implemented method may comprise receiving, by a streamingdata platform, a transaction object corresponding to a transaction. Thetransaction object may comprise transaction details and transactionmetadata. Further, the transaction metadata may comprise an indicationof a workflow corresponding to a transaction type of the transactionobject in which the workflow corresponding to the transaction typecomprises a first plurality of processing steps to process thetransaction. The computer-implemented method may further comprisedetermining, by a classification microservice and based on thetransaction details associated with the transaction object, whether thetransaction object comprises information that would allow thetransaction object to be processed via an alternative workflow, whereinthe alternative workflow corresponds to an alternative transaction typeand comprises a second plurality of processing steps to process thetransaction differently from the first plurality of processing steps;sending, based on a determination that the transaction object can beprocessed via an alternative workflow, a request for approval to processthe transaction object via the alternative workflow; in response toreceiving approval, changing, by the classification microservice, theindication of the workflow to the alternative workflow; adding, by theclassification microservice, the transaction object to the streamingdata platform; retrieving, by a microservice of a plurality ofmicroservices, a plurality of transaction objects, wherein the pluralityof transaction objects comprises the transaction object; processing, bythe microservice and based on a determination that a current workflowstage of the transaction object matches a first workflow stageassociated with the microservice, the transaction object; determiningthat the current workflow stage of the transaction object indicates thatthe transaction object has completed processing corresponding to thealternative workflow; and removing the transaction object from thestreaming data platform and outputting the transaction object and anindication that the transaction object has completed the processingcorresponding to the alternative workflow to a downstream system.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a computing device to perform operations comprising:receiving a transaction object corresponding to a transaction, whereinthe transaction object comprises transaction details and transactionmetadata, and wherein the transaction metadata comprises: an indicationof a workflow corresponding to a transaction type of the transactionobject, wherein the workflow corresponding to the transaction typecomprises a first plurality of processing steps to process thetransaction; determining, by a classification microservice and based onthe transaction details associated with the transaction object, whetherthe transaction object comprises information that would allow thetransaction object to be processed via an alternative workflow, whereinthe alternative workflow corresponds to an alternative transaction typeand comprises a second plurality of processing steps to process thetransaction differently from the first plurality of processing steps;sending, based on a determination that the transaction object can beprocessed via an alternative workflow, a request for approval to processthe transaction object via the alternative workflow; in response toreceiving approval, changing, by the classification microservice, theindication of the workflow to the alternative workflow; adding, by theclassification microservice, the transaction object to a streaming dataplatform; retrieving, by a microservice of a plurality of microservices,a plurality of transaction objects, wherein the plurality of transactionobjects comprises the transaction object; processing, by themicroservice and based on a determination that a current workflow stageof the transaction object matches a first workflow stage associated withthe microservice, the transaction object; determining that the currentworkflow stage of the transaction object indicates that the transactionobject has completed processing corresponding to the alternativeworkflow; and removing the transaction object from the streaming dataplatform and outputting the transaction object and an indication thatthe transaction object has completed the processing corresponding to thealternative workflow to a downstream system.

According to some aspects, a transaction exchange platform may comprise:a streaming data platform; a plurality of microservices comprising atleast a classification microservice and a microservice, wherein eachmicroservice of the plurality of microservices is configured to watchfor transactions on the streaming data platform in a correspondingworkflow stage based on a plurality of workflows corresponding to aplurality of transaction types; at least one processor; and memorystoring instructions that, when executed by the at least one processor,cause the transaction exchange platform to: receive, by the streamingdata platform, a transaction object corresponding to a transaction,wherein the transaction object comprises transaction details andtransaction metadata, and wherein the transaction metadata comprises: anindication of a workflow corresponding to a transaction type of thetransaction object, wherein the workflow corresponding to thetransaction type comprises a first plurality of processing steps toprocess the transaction; determine, by the classification microserviceand based on the transaction details associated with the transactionobject, whether the transaction object comprises information that wouldallow the transaction object to be processed via an alternativeworkflow, wherein the alternative workflow corresponds to an alternativetransaction type and comprises a second plurality of processing steps toprocess the transaction differently from the first plurality ofprocessing steps; send, based on a determination that the transactionobject can be processed via an alternative workflow, a request forapproval to process the transaction object via the alternative workflow;in response to receiving approval, change, by the classificationmicroservice, the indication of the workflow to the alternativeworkflow; add, by the classification microservice, the transactionobject to a streaming data platform; retrieve, by the microservice, aplurality of transaction objects, wherein the plurality of transactionobjects comprises the transaction object; process, by the microserviceand based on a determination that a current workflow stage of thetransaction object matches a first workflow stage associated with themicroservice, the transaction object; determine that the currentworkflow stage of the transaction object indicates that the transactionobject has completed processing corresponding to the alternativeworkflow; and remove the transaction object from the streaming dataplatform and output the transaction object and an indication that thetransaction object has completed the processing corresponding to thealternative workflow to a downstream system.

Further, the computer-implemented method may comprise training the oneor more machine-learning models based on a plurality of previouslyprocessed transaction objects. Each of the plurality of previouslyprocessed transaction objects may comprise a transaction score. Further,the computer-implemented method may comprise dividing a plurality ofpreviously processed transaction objects into a plurality of transactionclusters corresponding to different transaction types; and training theone or more machine-learning models using different sets of theplurality of transaction clusters. The computer-implemented method maycomprise determining, by the classification microservice and using oneor more machine-learning models, a first transaction score forprocessing the transaction object according to the workflowcorresponding to the transaction type; and determining, by theclassification microservice and using the one or more machine-learningmodels, a second transaction score for processing the transaction objectaccording to the alternative workflow corresponding to the transactiontype, wherein the determination that the transaction object can beprocessed via an alternative workflow is further based on an indicationthat the second transaction score represents a more cost-effectiveapproach than the first transaction score. The computer-implementedmethod may comprise sending, by the classification microservice, one ormore requests for feedback to a random sampling of one or more clientsassociated with previously processed transaction objects; and inresponse to receiving the feedback from the one or more clients,training one or more machine-learning models to determine whether atransaction object can be processed via an alternative workflow based onthe feedback.

According to aspects described herein the classification microservicemay use one or more machine-learning models when determining whether thetransaction object comprises information that would allow thetransaction object to be processed via an alternative workflow.

More particularly, some aspects described herein may provide acomputer-implemented method comprising determining, by a streaming dataplatform, that processing of a transaction object according to a firstworkflow, corresponding to a transaction type of the transaction object,did not complete successfully; determining, by a classificationmicroservice and based on transaction details associated with thetransaction object, whether the transaction object comprises informationthat would allow the transaction object to be processed via a secondworkflow, wherein the second workflow corresponds to an alternativetransaction type and comprises a plurality of processing steps toprocess a transaction differently from a plurality of processing stepsassociated with the first workflow; sending, based on a determinationthat the transaction object can be processed via the second workflow, arequest for approval to process the transaction object via the secondworkflow; adding, by the classification microservice and based onreceiving approval to process the transaction object via the secondworkflow, the transaction object to the streaming data platform with anindication of the second workflow; retrieving, by a microservice, aplurality of transaction objects, wherein the plurality of transactionobjects comprises the transaction object; processing, by themicroservice and based on a determination that a current workflow stageof the transaction object matches a first workflow stage associated withthe microservice, the transaction object; determining that the currentworkflow stage of the transaction object indicates that the transactionobject has completed processing corresponding to the second workflow;and removing the transaction object from the streaming data platform andoutputting the transaction object with an indication that thetransaction object has completed the processing corresponding to thesecond workflow to a downstream system.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a computing device to perform operations comprising:determining that processing of a transaction object according to a firstworkflow, corresponding to a transaction type of the transaction object,did not complete successfully; determining, by a classificationmicroservice and based on transaction details associated with thetransaction object, whether the transaction object comprises informationthat would allow the transaction object to be processed via a secondworkflow, wherein the second workflow corresponds to an alternativetransaction type and comprises a plurality of processing steps toprocess a transaction different from a plurality of processing stepsassociated with the first workflow; sending, based on a determinationthat the transaction object can be processed via the second workflow, arequest for approval to process the transaction object via the secondworkflow; adding, by the classification microservice and based onreceiving approval to process the transaction object via the secondworkflow, the transaction object to a streaming data platform with anindication of the second workflow; retrieving, by a microservice, aplurality of transaction objects, wherein the plurality of transactionobjects comprises the transaction object; processing, by themicroservice and based on a determination that a current workflow stageof the transaction object matches a first workflow stage associated withthe microservice, the transaction object; determining that the currentworkflow stage of the transaction object indicates that the transactionobject has completed processing corresponding to the second workflow;and removing the transaction object from the streaming data platform andoutputting the transaction object with an indication that thetransaction object has completed the processing corresponding to thesecond workflow to a downstream system.

According to some aspects, a transaction exchange platform may comprise:a streaming data platform; a plurality of microservices comprising atleast a classification microservice and a microservice, wherein theclassification microservice and the microservice are automaticallyconfigured to watch for transactions on the streaming data platform incorresponding workflow stages based on a plurality of workflowscorresponding to a plurality of transaction types; at least oneprocessor; and memory storing instructions that, when executed by the atleast one processor, cause the transaction exchange platform to:determine, by the streaming data platform, that processing of atransaction object according to a first workflow, corresponding to atransaction type of the transaction object, did not completesuccessfully; determine, by the classification microservice and based ontransaction details associated with a transaction object, whether thetransaction object comprises information that would allow thetransaction object to be processed via a second workflow, wherein thesecond workflow corresponds to an alternative transaction type andcomprises a plurality of processing steps to process a transactiondifferent from a plurality of processing steps associated with the firstworkflow; send, based on a determination that the transaction object canbe processed via the second workflow, a request for approval to processthe transaction object via the second workflow; add, by theclassification microservice and based on receiving approval to processthe transaction object via the second workflow, the transaction objectto the streaming data platform with an indication of the secondworkflow; retrieve, by the microservice, a plurality of transactionobjects, wherein the plurality of transaction objects comprises thetransaction object; process, by the microservice and based on adetermination that a current workflow stage of the transaction objectmatches a first workflow stage associated with the microservice, thetransaction object; determine that the current workflow stage of thetransaction object indicates that the transaction object has completedprocessing corresponding to the second workflow; and remove thetransaction object from the streaming data platform and output thetransaction object with an indication that the transaction object hascompleted the processing corresponding to the second workflow to adownstream system.

According to aspects described herein determining, by the classificationmicroservice, whether the transaction object comprises information thatwould allow the transaction object to be processed via the secondworkflow may comprise determining, by the classification microservice, afirst transaction cost associated with completing the transaction usingthe first workflow; and determining, by the classification microserviceand using one or more machine-learning models, a second transaction costfor processing the transaction object according to the second workflow,wherein the determination that the transaction object can be processedvia the second workflow is further based on an indication that thesecond transaction cost represents a more cost-effective approach thanthe first transaction cost. The first transaction cost and the secondtransaction cost may comprise at least one of: payor transaction costs,payee transaction costs, or processing entity transaction costs.Further, the first transaction cost and the second transaction cost maycomprise late fees associated with untimely completion of thetransaction processing.

According to aspects described herein determining, by the classificationmicroservice, whether the transaction object comprises information thatwould allow the transaction object to be processed via the secondworkflow may comprise determining, by the classification microservice,based on transaction metadata associated with the transaction object, afirst transaction speed associated with processing the transactionaccording to the first workflow; and determining, by the classificationmicroservice, based on one or more machine-learning models, a secondtransaction speed associated with processing the transaction accordingto the second workflow, wherein the determination that the transactionobject can be processed via the second workflow is further based thesecond transaction speed being faster than the first transaction speed.

According to aspects described herein determining, by the classificationmicroservice, whether the transaction object comprises information thatwould allow the transaction object to be processed via the secondworkflow may comprise determining, by the classification microservice, afirst security level associated with processing the transactionaccording to the first workflow; and determining, by the classificationmicroservice and based on one or more machine-learning models, a secondsecurity level associated with processing the transaction according tothe second workflow, wherein the determination that the transactionobject can be processed via the second workflow is further based on thesecond workflow at least as secure as the first workflow.

According to aspects described herein determining, by the classificationmicroservice, whether the transaction object comprises information thatwould allow the transaction object to be processed via the secondworkflow may comprise determining, by the classification microserviceand based on transaction metadata, a first completion probabilityassociated with processing the transaction according to the firstworkflow; and determining, by the classification microservice and basedon one or more machine-learning models analyzing the transactionmetadata, a second completion probability associated with processing thetransaction according to the second workflow, wherein the determinationthat the transaction object can be processed via the second workflow isfurther based on the second completion probability being greater than orequal to the first completion probability.

According to aspects described herein determining, by the classificationmicroservice, whether the transaction object comprises information thatwould allow the transaction object to be processed via the secondworkflow may comprise determining, by the classification microserviceand based on transaction metadata, a first scalability associated withprocessing the transaction according to the first workflow; anddetermining, by the classification microservice and based on one or moremachine-learning models analyzing the transaction metadata, a secondscalability associated with processing the transaction according to thesecond workflow, wherein the determination that the transaction objectcan be processed via the second workflow is further based on the secondscalability being greater than or equal to the first scalability.

According to aspects described herein determining, by the classificationmicroservice, whether the transaction object comprises information thatwould allow the transaction object to be processed via the secondworkflow may be based on a determination that the second workflow is atleast as efficient as the first workflow.

According to aspects described herein determining, by the classificationmicroservice, whether the transaction object comprises information thatwould allow the transaction object to be processed via the secondworkflow may comprise determining, by the classification microservice, atransaction deadline associated with the transaction, wherein thedetermination that the transaction object can be processed via thesecond workflow is further based on the second workflow completingprocessing of the transaction before the transaction deadline.

Corresponding apparatus, systems, devices, and one or morenon-transitory computer-readable media are also within the scope of thedisclosure.

These features, along with many others, are discussed in greater detailbelow.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is illustrated by way of example and not limitedin the accompanying figures in which like reference numerals indicatesimilar elements and in which:

FIG. 1 depicts an example of a computing device that may be used inimplementing one or more aspects of the disclosure in accordance withone or more illustrative aspects discussed herein;

FIG. 2 depicts an example operating environment used to discussillustrative aspects of a transaction exchange according to one or moreaspects of the disclosure;

FIG. 3A depicts an example transaction exchange platform according toone or more aspects of the disclosure;

FIGS. 3B-3C depict example structures for microservices according to oneor more aspects of the disclosure;

FIG. 4 depicts an illustrative workflow as a directed acyclic graphaccording to one or more aspects of the disclosure;

FIG. 5 depicts an illustrative method for processing transactions on astreaming data platform according to one or more aspects of thedisclosure;

FIG. 6 depicts an example transaction exchange platform having aconfiguration interface according to one or more aspects of thedisclosure;

FIGS. 7A-7C depict illustrative changes to workflows, as graphs,according to one or more aspects of the disclosure;

FIG. 8 depicts an illustrative method for reconfiguring microservicesaccording to one or more aspects of the disclosure;

FIG. 9 depicts an example transaction exchange platform having asnapshot microservice and a watchdog microservice according to one ormore aspects of the disclosure;

FIGS. 10-15 depict illustrative methods for operation of the snapshotmicroservice and the watchdog microservice according to one or moreaspects of the disclosure;

FIG. 16 depicts an example transaction exchange platform having aclassification microservice according to one or more aspects of thedisclosure;

FIG. 17 depicts a flowchart illustrating an example method for trainingmachine-learning models for use in a transaction exchange platformaccording to one or more aspects of the disclosure;

FIG. 18 depicts an illustrative method for processing transactions on astreaming data platform according to one or more aspects of thedisclosure; and

FIG. 19 depicts an illustrative method for processing transactions on astreaming data platform according to one or more aspects of thedisclosure.

DETAILED DESCRIPTION

In the following description of the various embodiments, reference ismade to the accompanying drawings, which form a part hereof, and inwhich is shown by way of illustration various embodiments in whichaspects of the disclosure may be practiced. It is to be understood thatother embodiments may be utilized and structural and functionalmodifications may be made without departing from the scope of thepresent disclosure. Aspects of the disclosure are capable of otherembodiments and of being practiced or being carried out in various ways.Also, it is to be understood that the phraseology and terminology usedherein are for the purpose of description and should not be regarded aslimiting. Rather, the phrases and terms used herein are to be giventheir broadest interpretation and meaning. The use of “including” and“comprising” and variations thereof is meant to encompass the itemslisted thereafter and equivalents thereof as well as additional itemsand equivalents thereof.

By way of introduction, aspects described herein may relate to atransaction exchange platform using a streaming data platform andmicroservices to process transactions according to review and approvalworkflows. A transaction exchange platform, according to one or moreaspects discussed herein, may provide a version agnostic data streaming,reactive microservice solution that facilitates payment relatedworkflows to be executed. Although the term “microservice” is usedthroughout this disclosure, aspects are not limited to “microservices”as used in cloud computing contexts. Generally, as used herein“microservice” may refer to a technology process that does work on anobject on a streaming data platform in any given step of a workflow.Aspects discussed herein may refer to “approval” of transactions. Thisgenerally refers to the processing necessary to move a transactionthrough the transaction exchange platform from intake to output, anddoes not necessarily mean that the payment exchange platformaffirmatively approves the nature of the transaction. Instead,“approval” as used herein may refer to processing, validating, and/oraffirmatively approving a transaction according to a workflow indicatingthe steps necessary to process a transaction on the platform before itis ready for output to downstream processors. Some aspects may providefor dynamic and flexible reconfiguration of workflows and/ormicroservices. Other aspects may provide for data snapshots and workflowtracking, allowing for monitoring, quality control, and auditability.Furthermore, other aspects may provide for dynamic and flexibleclassification of transaction objects in order to determine alternativeworkflows that may more effectively process the transaction objects.Additionally, other aspects may provide for determination and/ordetection of transaction objects that did not successfully completeprocessing using a first workflow. The system can then determine asecondary workflow to successfully complete processing of thetransaction object. Each of these aspects may work in concert to providea flexible, robust, and auditable processing platform for transactionclearing and approval.

Before discussing these concepts in greater detail, however, severalexamples of a computing device that may be used in implementing and/orotherwise providing various aspects of the disclosure will first bediscussed with respect to FIG. 1 .

FIG. 1 illustrates one example of a computing device 101 that may beused to implement one or more illustrative aspects discussed herein. Forexample, computing device 101 may, in some embodiments, implement one ormore aspects of the disclosure by reading and/or executing instructionsand performing one or more actions based on the instructions. In someembodiments, computing device 101 may represent, be incorporated in,and/or include various devices such as a desktop computer, a computerserver, a mobile device (e.g., a laptop computer, a tablet computer, asmart phone, any other types of mobile computing devices, and the like),and/or any other type of data processing device.

Computing device 101 may, in some embodiments, operate in a standaloneenvironment. In others, computing device 101 may operate in a networkedenvironment. As shown in FIG. 1 , various network nodes 101, 105, 107,and 109 may be interconnected via a network 103, such as the Internet.Other networks may also or alternatively be used, including privateintranets, corporate networks, LANs, wireless networks, personalnetworks (PAN), and the like. Network 103 is for illustration purposesand may be replaced with fewer or additional computer networks. A localarea network (LAN) may have one or more of any known LAN topology andmay use one or more of a variety of different protocols, such asEthernet. Devices 101, 105, 107, 109 and other devices (not shown) maybe connected to one or more of the networks via twisted pair wires,coaxial cable, fiber optics, radio waves or other communication media.

As seen in FIG. 1 , computing device 101 may include a processor 111,RAM 113, ROM 115, network interface 117, input/output interfaces 119(e.g., keyboard, mouse, display, printer, etc.), and memory 121.Processor 111 may include one or more computer processing units (CPUs),graphical processing units (GPUs), and/or other processing units such asa processor adapted to perform computations associated with machinelearning. I/O 119 may include a variety of interface units and drivesfor reading, writing, displaying, and/or printing data or files. I/O 119may be coupled with a display such as display 120. Memory 121 may storesoftware for configuring computing device 101 into a special purposecomputing device in order to perform one or more of the variousfunctions discussed herein. Memory 121 may store operating systemsoftware 123 for controlling overall operation of computing device 101,control logic 125 for instructing computing device 101 to performaspects discussed herein, machine learning software 127, smart database129, and other applications 131. Machine learning software 127 may beincorporated in and may be a part of control logic 125. In embodiments,computing device 101 may include two or more of any and/or all of thesecomponents (e.g., two or more processors, two or more memories, etc.)and/or other components and/or subsystems not illustrated here. Further,the machine learning software 127 may include and/or use one or moremachine-learning models described herein.

Devices 105, 107, 109 may have similar or different architecture asdescribed with respect to computing device 101. Those of skill in theart will appreciate that the functionality of computing device 101 (ordevice 105, 107, 109) as described herein may be spread across multipledata processing devices, for example, to distribute processing loadacross multiple computers, to segregate transactions based on geographiclocation, user access level, quality of service (QoS), etc. For example,devices 101, 105, 107, 109, and others may operate in concert to provideparallel computing features in support of the operation of control logic125 and/or machine learning software 127.

One or more aspects discussed herein may be embodied in computer-usableor readable data and/or computer-executable instructions, such as in oneor more program modules, executed by one or more computers or otherdevices as described herein. Generally, program modules includeroutines, programs, objects, components, data structures, etc. thatperform particular tasks or implement particular abstract data typeswhen executed by a processor in a computer or other device. The modulesmay be written in a source code programming language that issubsequently compiled for execution, or may be written in a scriptinglanguage such as (but not limited to) HTML or XML. The computerexecutable instructions may be stored on a computer readable medium suchas a hard disk, optical disk, removable storage media, solid statememory, RAM, etc. As will be appreciated by one of skill in the art, thefunctionality of the program modules may be combined or distributed asdesired in various embodiments. In addition, the functionality may beembodied in whole or in part in firmware or hardware equivalents such asintegrated circuits, field programmable gate arrays (FPGA), and thelike. Particular data structures may be used to more effectivelyimplement one or more aspects discussed herein, and such data structuresare contemplated within the scope of computer executable instructionsand computer-usable data described herein. Various aspects discussedherein may be embodied as a method, a computing device, a dataprocessing system, or a computer program product.

Having discussed several examples of computing devices which may be usedto implement some aspects as discussed further below, discussion willnow turn to methods and techniques for implementing a transactionexchange platform.

Transaction Exchange Platform—Processing Streaming Transaction DataUsing Microservices

Aspects described herein may provide a transaction exchange platformimplemented using a streaming data platform (SDP) and a plurality ofmicroservices to process transactions according to workflowscorresponding to different transaction types. Microservices on thetransaction exchange platform may be configured to retrieve transactionshaving a current workflow stage that is assigned to the microservicefrom the SDP. The microservice may perform one or more steps of theapproval/review workflow for the type of transaction, update the statusof the object, and put it back to the SDP. Other microservices, later inthe workflow, may see that the current workflow status of a transactionindicates that earlier pre-requisite processing steps have completed andmay accordingly retrieve the transaction objects and perform theirrespective workflow steps. When the current workflow stage of atransaction indicates that all requisite steps of the workflow have beencompleted, the transaction may be removed from the SDP of thetransaction exchange platform and output to downstream systems forfurther processing.

A high-level system 200 for processing transactions, such as payments,is illustrated in FIG. 2 . Transaction processing system 200 may broadlyillustrate the flow of transactions from origination source 205 throughto settlement systems 220. Transactions handled by system 200 may takeany suitable form, generally as payment transactions. Example types ofpayment transactions include: wires, automated clearing house (ACH)payments, checks, cashier checks, real-time payments (RTP), creditcards, and/or many other types of payment transactions. Other factorsthat may inform the “type” of a transaction may include whether thetransaction originates domestically or internationally, whether thedestination is domestic or international, an amount of the transaction,the identity of one or more financial entities associated with thetransaction, and the like. For purposes of the discussion herein, atransaction type may be relevant primarily for informing thereview/approval steps that should be applied to the transaction prior tofinal settlement.

Transactions may begin at origination sources 205. For example, if acustomer were to purchase a donut at a bakery using a credit card, thetransaction may be sent via a point-of-sale (POS) terminal at the bakeryto a payment processor. As another example, an investor may cause a wirepayment to be sent to their broker via a banking website. The bankingwebsite may receive the wire payment transaction and begin the processof facilitating settlement of the wire transaction via a transactionprocessing system 200.

Transactions may be routed to settlement systems 220 to effect thetransfer of the monies indicated in the transaction. For example, thewire transaction may be routed to respective financial institutionsassociated with the investor and broker to indicate the respectivedebit/credit to their accounts. However, substantial review and approvalprocessing may be required before a transaction may be settled. Thisprocessing may involve regulatory, security, and/or risk management.

Transaction exchange platform 210 may serve as an interface between theorigination source 205 and settlement systems 220, and according to someaspects may implement the transaction review and approval workflow foreach supported transaction type. Origination sources 205 may sendtransactions to transaction exchange platform 210 for review andapproval processing, and ultimately for routing to settlement systems220. Transaction exchange platform 210 may be provided by the sameentity that operates settlement systems 220 and/or one or more oforigination sources 205, or may be provided by a third-party entity.

Transaction exchange platform 210 may perform the review and approvalprocessing for transactions. This may include interfacing with clearingsystems 215. Clearing systems 215 may provide regulatory, security,and/or risk management support for transactions. For example,transactions may be referred to systems provided by the U.S. FederalReserve as part of a clearance process. As another example, theidentities of the parties to the transaction may need to be evaluatedagainst various criteria in support of anti-money laundering or othersuch efforts. Clearing systems 215 may be provided as part oftransaction exchange platform 210, or as logically separate systems.Clearing systems 215 may be provided by the entities operatingorigination sources 205, transaction exchange platform 210, settlementsystems 220, government entities, and/or other third parties.

Transaction exchange platform 210 may interface with clearing systems215 to complete review and approval processing on the transaction.Transactions that are approved on transaction exchange platform 210 maybe routed to settlement systems 220 for settlement and/or furtherprocessing.

FIG. 3A illustrates a system 300 that may provide further details of anovel transaction exchange platform 320 than provided in FIG. 2 ,according to some aspects described herein. Similarly, transactions mayoriginate at transaction origination sources 303 and route to downstreamsettlement systems, illustrated in FIG. 3A as enterprise systems andusers 350.

Transaction exchange platform 320 may serve to perform review andapproval workflow processing on transactions received from transactionorigination sources 303 via enterprise transaction intermediary services305. Transaction origination sources 303 may include both first- andthird-party sources of transactions. The enterprise providingtransaction exchange platform 320 may provide transaction intermediaryservices 305 to receive transactions, whether from third-parties or not,and route those transactions to transaction exchange platform 320.Enterprise transaction intermediary service 305 may perform validation,pre-processing, standardization, and/or any other suitable processing toprepare transactions for further handling by transaction exchangeplatform 320.

Transactions may be sent to transaction exchange platform 320 viaapplication programming interfaces (APIs), such as API 311 and API 313.The APIs may validate aspects of the transaction details, and maypackage and/or standardize transactions into transaction objectssuitable for processing on transaction exchange platform 320. In someimplementations, transaction exchange platform 320 may provide differentAPIs for each type of transaction. For example, API 311 may correspondto ACH transactions while API 313 corresponds to wire transactions. Insome implementations, fewer APIs (such as a single centralized API) maybe used to flexibly validate and initialize transactions for processingby transaction exchange platform 320. The APIs for interfacing withtransaction exchange platform 320 may comprise a number of components,such as a public API front-end, basic input validation logic, messagelevel integrity processes, monitoring, and/or integration aspects.

Transaction objects may be pushed to a streaming data platform (SDP) 325underlying transaction exchange platform 320. Streaming data platforms,such as those based on the Apache Kafka open-source platform, may beused to process real-time data in computer systems. Message objectspushed to the streaming data platform may be read by consumer softwaremodules, processed, and put back to the streaming data platform.Transaction objects on SDP 325 may be subject to processing bymicroservices on transaction exchange platform 320, such as microservice331, microservice 332, and microservice 333. The microservices can readand write transaction objects from/to SDP 325. Objects on SDP 325 mayproceed logically through time, e.g. t₀ through t_(n), as they progressthrough stages of the workflow associated with a correspondingtransaction type.

Transaction objects, such as transaction object 307, may includetransaction details, addenda, and transaction metadata. The transactiondetails and/or addenda may include the particulars of the transaction,such as the parties and/or accounts involved, as well as the amount ofthe payment. Addenda data of the transaction object may include, e.g.,ABA routing numbers and other details that may be added, updated, and/orprocessed by the microservices on transaction exchange platform 320. Thetransaction metadata may include at least an indication of a workflowcorresponding to a transaction type of the transaction object and acurrent workflow stage of the transaction object. In someimplementations, discussed further herein, the transaction metadata mayalso include workflow version information.

As an example, transaction object 307 may include the following:

{  transaction ID : a SHA256 encoded token  workflow type : ACH  currentworkflow stage : init  transaction details : ISO20022 token  addendadata { ABA routing : xyz } }Transaction object 307 may encapsulate any suitable standard paymentobject, such as one storing transaction details in a recognized JSONformat. As mentioned, and as illustrated further in FIG. 6 , transactionobjects may also include a current workflow version assigned to thetransaction object. Still other metadata may be included, such as areplay tracking count indicating the number of times that thetransaction has been subject to replay through one or more steps of theworkflow. Transaction details may be immutable, not subject to changewhile the transaction object is on the streaming data platform, whereasmetadata and/or addenda data may be subject to change through additions,removals, updates, and/or other processing or modification by themicroservices on transaction exchange platform 320.

A current workflow stage value may be maintained as part of thetransaction metadata in each transaction object. The current workflowstage may indicate which processing steps of the associated workflowhave been completed on the transaction. The current workflow stage mayindicate the completion status of each respective step of the workflow.As such, in an example implementation the current workflow stage valuemay be a set of values and/or a data structure indicating the completionof individual workflow steps, e.g. processing by respectivemicroservices. Microservices may be configured to listen to the SDP fortransactions having a current workflow stage value that indicatescompletion of each of the pre-requisite steps for processing by themicroservice.

Microservices on the transaction exchange platform may listen to the SDPto identify and retrieve transaction objects having a current workflowstage matching a workflow stage associated with the microservice.Transaction objects matching the microservice's assigned workflow stagemay be processed by the microservice for review, approval, and/or anyother suitable processing as part of the overall series of stepsrequired to approve a transaction of the corresponding transaction type.Processing may result in updating one or more elements of thetransaction metadata. Once the microservice completes its processing ofthe transaction object, the microservice can put the transaction objectback to the SDP with an updated current workflow stage indicating thatthe microservice completed its processing. The updated transactionobject may then be identified and processed by a next microservice basedon the workflow.

Turning briefly to FIGS. 3B and 3C, FIG. 3B illustrates an examplestructure for a microservice 330N. The microservice may comprisesubcomponents configured to work in concert to apply processing logicassociated with a workflow step assigned to the microservice. In theillustrated structure, microservice 330N comprises a stream listener3301 which may operate as a standardized way to read from SDP 325 andconsume transaction objects that meet the workflow criteria (e.g.,stage) associated with microservice 330N. Microservice 330N may alsoinclude private API 3302, which may be a RESTful implementation used insynchronous calls supporting singleton integrations into transactionexchange platform 320, and its use may allow only the response to beexposed to the public API aspect of microservice 330N. Microservice 330Nmay also include core logic 3303, which may contain the business logicand associated computer instructions to fulfill microservice 330N'sassigned role in the workflow. Core logic 3303 may be adapted to processtransaction objects in accordance with one or more steps of regulatory,security, and/or risk management processes. Microservice 330N mayfurther include transient data 3304, which may include a data managementlayer that deals with data that is attributed to the local functionalityof the system, for example truth tables used in processing by core logic3303, and persistent data 3307, which may include a construct to capturestate data for the associated workflow stage. Microservice 330N mayfurther include messaging components 3305 to track message levelintegrity via natural key encryption derivations of the payment object.And microservice 330N may include monitoring components 3306, configuredto provide oversight and tracking, and integration components 3308,configured to provide the ability to integrate with software structurepatterns such as Async SDP, SOAP, RESTful API, and the like. Asillustrated in FIG. 3C, however, a microservice may be made up of acollection of other microservices. For example, as illustratedmicroservice 331N comprises component microservices 3321, 3322, and3323.

Returning to FIG. 3A, illustrative transaction exchange platform 320includes three microservices (microservices 331, 332, and 333)configured to operate on ACH transactions. Transaction object 307 is anexample ACH transaction, and is added to SDP 325 via API 311.Transaction object 307 may be added to SDP 325 in an “init” orinitialization stage, indicating that none of the workflow steps haveyet been completed. In some implementations, the initialization stagemay be a separate stage that is marked completed prior to processing bya first microservice, or may be commensurate in scope with a firstworkflow stage associated with a first microservice of the workflow. Insome implementations, the initialization stage for the object may behandled as part of the processing by the APIs 311, 313 or otherwisehandled alongside workflow processing by the respective microservices.

Walking through the example, transaction object 307 may be added to SDP325 in the initialization stage (stage ‘0’). Microservice 331 may beconfigured to perform a first step in an approval workflow fortransaction having a transaction type of ACH. For example, microservice331 may be configured to verify that the recipient account of the ACHtransaction is valid. Microservice 331 may look for transaction objectson SDP 325 having a first workflow stage (stage ‘1’), for example astage that indicates initialization pre-processing was completed or, insome implementations, transaction objects in the initialization stageitself. As mentioned above, the current workflow stage of transactionobject 307 may indicate each (and/or a subset) of the workflow stepsthat have been completed on transaction object 307, and the currentworkflow stage thus may comprise a data structure listing the completionstatus of each (and/or a subset) of the workflow steps. Microservice 331may listen to the SDP 325 to retrieve transaction objects having acurrent workflow stage matching (e.g., meeting) the first workflow stageassigned to microservice 331. In this manner, microservice 331 mayextract transaction objects from SDP 325 that have met the criteria formicroservice 331 to begin processing. For example, microservice 331 maybe configured to wait until initialization steps such as new objectsnapshotting is completed before performing its processing to verify therecipient account. Transaction objects retrieved by microservice 331 maybe removed and/or otherwise blocked on SDP 325 pending processing bymicroservice 331.

Microservice 331, having retrieved one or more transaction objects suchas transaction object 307, may perform its corresponding workflow stepon the transaction object. The workflow step may comprise suitableprocessing of the transaction object, such as according to core logic ofmicroservice 331 (similar to core logic 3303 of FIG. 3B). Processing ofthe transaction object by microservice 331 (or any other microservice)may comprise any of: retrieving the transaction object; reviewing valuesand other characteristics of the transaction object; interfacing withclearing systems such as clearing systems 215 and/or other systems;comparing values or characteristics to rules, regulations, policies, andthe like; adding, removing, updating, or otherwise changing any aspectof the transaction addenda data or transaction metadata; generatingreports and/or alerts; presenting the transaction for manual or otherreview; and/or any other suitable processing associated with therespective step of the workflow for transactions of that type. Forexample, processing by a microservice may comprise verifying a value ofthe transaction details, addenda data, and/or transaction metadataagainst at least one rule. As another example, processing may compriseverifying a value of the transaction details, addenda data, and/ortransaction metadata against a watchlist. Processing may comprisedetermining that the transaction details, addenda data, and/ortransaction metadata fail at least one rule; flagging the transactionobject for further review; and holding the transaction object in thecurrent workflow stage pending the further review, where updating thecurrent workflow stage of the transaction object to the third workflowstage is based on determining that the further review is completed.Flagging the transaction object for further review may comprise flaggingthe transaction object for manual review by a user and/or setting thecurrent workflow stage of the transaction object to a current workflowstage associated with another microservice, other than the microservicethat typically processes transactions after the first microservice.

The processed transaction object may be put back to SDP 325 bymicroservice 331, and the current workflow stage of the transactionobject may be updated to indicate that microservice 331 has completedits processing. For example, transaction object 307 may be updated tohave a current workflow stage of ‘2’ after microservice 331 completesits processing.

Back on the SDP 325, the updated transaction object may be subject tofurther processing by other microservices in like fashion. For example,microservice 332 may correspond to a second step of processing in theworkflow corresponding to ACH transactions, such as a regulatory checkassociated with anti-money laundering efforts. Microservice 332 may beconfigured to look for transaction objects having a second currentworkflow stage, e.g., stage ‘2’, on SDP 325. Microservice 332 can listento the SDP 325 to retrieve such transaction objects and process themaccording to its own core logic, similarly to that described above withrespect to microservice 331. The processed transaction object may be putback to the SDP 325 with an updated current workflow stage indicatingthat processing by microservice 332 is completed. Microservice 333 maybe configured to look for a third current workflow stage, e.g. stage‘3’, and may process transaction objects similarly. For example,microservice 333 could perform processing to obligate a customer'saccount for the value of the transaction.

When the current workflow stage of a transaction object indicates it hascompleted the steps of the corresponding workflow, the transactionobject may be removed from SDP 325 and routed or otherwise madeavailable to other components of the overall transaction system. Forexample, the approved transaction object, having passed through allsteps of the corresponding workflow, may be published to a publicstreaming data platform 340 accessible outside of the transactionexchange platform. Enterprise systems, applications, users, and others(e.g. enterprise services and users 350) may access the completedtransaction objects on the public streaming data platform and furtherprocess for transaction settlement or other purposes.

The structure described herein, where microservices listen to the SDP325 for transaction objects having corresponding current workflowstages, may drive payments and other transactions through the system andrequisite review and approval workflows. As mentioned, the workflow fora given transaction type may comprise a plurality of processing stepsrequired to approve a given transaction of the transaction type.Workflows may be implemented in the configurations of what workflowstage metadata each microservice is configured to look for on the SDP325. However, workflows may also be logically described and/or definedusing a directed acyclic graph structure, as described further withrespect to FIG. 4 .

FIG. 4 illustrates a sample directed acyclic graph (DAG) 400 that maycorrespond to a workflow corresponding to transactions having a wiretransaction type. The steps of the workflow corresponding to a giventransaction type may be organized as a DAG. The DAG may comprise nodescorresponding to the individual steps of the workflow, and edgescorresponding to pre-requisite relationships between the steps. The DAGmay indicate how transactions from an origination source such asorigination 410 flow through the transaction exchange platform 320,until approval is completed and the transaction is ready for furtherprocessing by downstream systems. The DAG may include parallel paths,whereby the transaction object may be subject to concurrent processingby multiple microservices. The DAG may indicate pre-requisite conditionsthat govern the progression of the transaction object through the stagesof the workflow. For example, processing by a microservice in the DAGmay be conditioned on the completion of processing by one or more othermicroservices. The DAG may also indicate branching, conditional pathswhere a transaction object may be subject to processing by differentmicroservices (and/or different processing generally) based on certaintransaction attributes.

In the example workflow for wire transactions 400 illustrated in FIG. 4, a transaction object added to transaction exchange platform 320 fromorigination 410 may first enter step ‘A’. Step ‘A’ may correspond to amicroservice that performs processing to verify that a recipient accountin the transaction details and/or addenda is valid. Once step ‘A’processing is complete, the workflow proceeds to step ‘B’, which maycorrespond to a high value thresholder that operates to splittransactions for different processing based on their value (alsoimplemented as a microservice). For example, once step ‘A’ is completedand a first microservice updates the current workflow stage of thetransaction object, a microservice associated with step ‘B’ may pick upthe transaction object and determine if it involves a payment over acertain value, e.g., payments more than $5000. The microserviceassociated with step ‘B’ may update the transaction object withdifferent current workflow stages depending on whether the transactionshould be subject to high value processing (e.g., step ‘C’) or standardprocessing (e.g., step ‘D’). Step ‘C’ may occur subsequent to step ‘B’determining that a high value transaction should be subject to enhancedverification, and may comprise performing the enhanced verification by acorresponding microservice. Step ‘D’ may comprise performing standardregulatory verification by a corresponding microservice. Step ‘D’ mayalso determine if the transaction is an international or domestic wire,and may update the current workflow stage and/or other transactionmetadata accordingly. If the transaction is an international wire, itmay be routed (by means of the updated transaction metadata) to amicroservice associated with step ‘E’, which may perform furtherinternational wire processing. If the transaction is a domestic wire, itmay proceed to step ‘F’ once regulatory checks are completed. Step ‘F’may comprise a step to obligate the customer's account for the amount ofthe wire, and may be conditioned on successful completion of steps ‘C’,‘D’, or ‘E’ depending on how the transaction progressed through theworkflow. For example, a microservice corresponding to step ‘F’ may beconfigured to listen to the SDP 325 for transactions having a currentworkflow stage that indicates they have completed steps ‘C’, ‘D’, or‘E’. Finally, completing the workflow step ‘G’ may correspond to amicroservice configured to send the wire transaction for settlement,such as to settlement systems 220 of FIG. 2 or enterprise services andusers 350 of FIG. 3A. Having completed workflow step ‘G’, thetransaction metadata may be updated to indicate completion of theworkflow. For example, the current workflow stage of the transactionobject may be updated to indicate completion of step ‘G’. As anotherexample, the current workflow stage of the transaction object mayreflect the completion of each of steps ‘A’, ‘B’, ‘D’, ‘F’, and ‘G’.

Workflow 400 is just one example of a workflow corresponding to atransaction type, and the transaction exchange platform 320 may havemany such workflows corresponding to different transaction types.Microservices on transaction exchange platform 320 may be involved inone or more workflows, and may operate on different stages of differentworkflows.

Workflow steps may proceed in parallel, and may be independent of one ormore other steps in the workflow. For example, if validating the accountnumber of the sending party and validating the account number of thereceiving party were handled by different microservices, the workflowmay indicate that both may occur once the transaction is brought ontothe platform. However, later steps may be conditioned on the completionof both steps. Either step may occur first in time, depending on theavailability of each respective microservice to handle the transaction.

Microservices on transaction exchange platform 320 may be automaticallyconfigured to look for a corresponding current workflow stage. Thisautomatic configuration may be based on the DAG structure used tologically define the workflow. For example, the individual microservicesmay be automatically configured to listen to the SDP 325 fortransactions having a current workflow stage that indicates that thepre-requisite criteria represented in the DAG is met prior to processingby the microservice. Each microservice may be configured to look fortransaction objects on SDP 325 that have a given workflow type and alsohave a current workflow stage matching that assigned to themicroservice. Thus, microservices may be configured to operate as partof multiple workflows, and can look for transaction objects at differentstages of the workflows. As discussed further herein with respect toFIG. 6 , changes to the DAG may be used to automatically re-configurethe microservices to watch for transaction objects in differentworkflows and/or different workflow stages.

FIG. 5 depicts a flowchart illustrating an example method 500 to processtransactions by a transaction exchange platform, such as transactionexchange platform 320. Method 500 may be performed by any suitablecomputing device and/or combination of computing devices, referred to asthe system implementing method 500.

At step 505, the system may configure microservices on the transactionexchange platform to watch for transactions of the streaming dataplatform (SDP) that have transaction metadata indicating that they arein a current workflow stage corresponding to the individualmicroservice. As discussed above with respect to FIG. 4 , the system mayautomatically configure the microservices based on a DAG structure thatlogically defines the steps of the workflow and their relationships.

At step 510, the system may receive a transaction object and add it tothe streaming data platform. The transaction object may be received froma transaction origination source such as origination source 303, and maybe received from an enterprise intermediary service, such as enterprisetransaction intermediary service 305. The transaction object may bereceived via one or more APIs of the transaction exchange platform, suchas APIs 311 and 313 of transaction exchange platform 320. Thetransaction object may be added to the SDP in an initialization stage,which may be implemented through setting a current workflow stage of thetransaction object's transaction metadata to an initialization value.The initialization stage may be separate from a first workflow stageassociated with a first microservice of the workflow, or could be thesame as the first workflow stage. Objects in the initialization stagemay be subject to various system processes on the transaction exchangeplatform, such as format or other verifications, standardization,snapshots, and the like. If the initialization stage is separate from afirst workflow stage of the workflow, the transaction object may beupdated to have the first workflow stage once initialization processingis completed.

The transaction object, on the SDP, may be subject to processing by oneor more microservices including first microservice 520 and secondmicroservice 530. First microservice may be configured to listen to theSDP for transactions in a first workflow stage, while secondmicroservice may be configured to listen to the SDP for transactions ina second workflow stage.

At step 521, first microservice 520 may listen to the SDP fortransactions having a particular workflow type (corresponding to atransaction type) and having a first workflow stage within that workflowcorresponding to first microservice 520. The SDP may identifytransaction objects that have a current workflow stage value thatmatches the first workflow stage criteria associated with the firstmicroservice 520. Identification of matching transaction may be based ontransaction metadata indicating a type of workflow, a current workflowstage, and other information associated with the workflow (such asworkflow version information, discussed below with respect to FIG. 6 ).At step 523, first microservice 520 may retrieve the matchingtransaction objects for processing. Although steps 521 and 523 areillustrated separately, it will be understood that in practice they maybe part of a single contiguous act.

At step 525, first microservice 520 may process the transaction objectsit retrieved from the SDP according to processing logic associated withfirst microservice 520. Processing a transaction object may include:reviewing, assessing, analyzing, updating, adding to, removing, and/orany other suitable processing of the transaction data, addenda data,and/or transaction metadata associated with the transaction object.

At step 527, first microservice 520 may update a current workflow stageof the transaction object to indicate completion of the processingcorresponding to first microservice 520. In some embodiments, thecurrent workflow stage may be updated to different next step valuesdepending on the processing by first microservice 520. For example, asdiscussed with respect to workflow 400 in FIG. 4 , a microservice mayupdate the current workflow stage of a transaction object to route it todifferent next microservices depending on whether it meets certaincriteria, such as having a value greater than a threshold amount.

At step 529, first microservice 520 may put the updated transactionobject back to the SDP. The updated transaction object may have one ormore changed values (or none) of its transaction data, addenda data,and/or transaction metadata, in addition to the updated current workflowstage.

In the example of method 500, first microservice 520 may update thecurrent workflow stage of the transaction object to indicate completionof processing by the first microservice 520. This updated currentworkflow stage may correspond to the second current workflow stage thatsecond microservice 530 is looking for on the SDP.

Thus, at step 531, the second microservice 530 may listen to the SDP fortransactions having the second workflow stage and, at step 533, mayretrieve transaction objects matching the second workflow stage. Thesecond microservice 530 may perform similar processing to that describedabove with respect to first microservice 520. That is, steps 531, 533,535, 537, and 539 may be analogous to steps 521, 523, 525, 527, and 529,modified as appropriate for the role assigned to second microservice 530in the workflow for a given transaction type. The processed, updatedtransaction object may be put back to the SDP with an updated currentworkflow stage indicating completion of the processing corresponding tosecond microservice 530.

At step 540, the system may determine that the current workflow stagemetadata of the transaction object indicates that all requisiteprocessing steps of the workflow have been completed. As a result,processing by the transaction exchange platform may be completed and theapproved transaction object may be removed from the SDP and output forfurther processing and/or settlement. For example, as illustrated inFIG. 3A, a completed, approved transaction may be output to a public SDPfor access by downstream systems and users.

Thus, according to some embodiments a computer-implemented method mayreceive a transaction object comprising transaction details andtransaction metadata. That transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The computer-implemented method may furthercomprise adding the transaction object to a streaming data platform andupdating the current workflow stage of the transaction object to a firstworkflow stage. A first microservice may listen to the streaming dataplatform to retrieve transactions matching the first workflow stage. Thefirst workflow stage may be associated with the first microservice basedon the workflow corresponding to the transaction type. The firstmicroservice may retrieve, from the streaming data platform, thetransaction object based on the current workflow stage matching thefirst workflow stage. The first microservice may process the transactionobject. The computer-implemented method may further comprise updatingthe current workflow stage of the transaction object to a secondworkflow stage based on completing processing, by the firstmicroservice, of the transaction object. A second microservice maylisten to the streaming data platform to retrieve transactions matchingthe second workflow stage. The second workflow stage may be associatedwith the second microservice based on the workflow corresponding to thetransaction type. The second microservice may retrieve, from thestreaming data platform, the transaction object based on the currentworkflow stage matching the second workflow stage. The secondmicroservice may process the transaction object. Thecomputer-implemented method may further comprises updating the currentworkflow stage of the transaction object to a third workflow stage basedon completing processing, by the second microservice, of the transactionobject; determining that the current workflow stage of the transactionobject indicates that the transaction object has completed processingcorresponding to the workflow; and removing the transaction object fromthe streaming data platform and outputting the transaction object and anindication that the transaction object has completed the processingcorresponding to the workflow.

The first and second microservice may be automatically configured towatch for transactions on the streaming data platform in the first andsecond workflow stages, respectively, based on the plurality ofprocessing steps. A different second workflow may be associated with asecond transaction type and may comprise a different second plurality ofprocessing steps required to approve a given transaction of the secondtransaction type. The second transaction type may be different from thetransaction type. The first microservice may operate on transactionsassociated with both the workflow and the different second workflow. Theplurality of processing steps of the workflow may indicate that thefirst microservice processes the transaction object at a different stagethan the different second plurality of processing steps of the differentsecond workflow.

The workflow corresponding to the transaction type may comprise adirected acyclic graph (DAG) indicating the plurality of processingsteps required to approve a given transaction of the transaction type.The first and second microservice may be automatically configured towatch for transactions on the streaming data platform in the first andsecond workflow stages, respectively, based on the DAG. Thecomputer-implemented method may further comprise, responsive to anupdate to at least one of the plurality of processing steps indicated inthe DAG, automatically reconfiguring at least one microservice based onthe update.

The current workflow stage of the transaction object may comprise a datastructure indicating completion status of each respective step of aplurality of processing steps associated with the workflow. Thetransaction object may be updated to have a current workflow stagecorresponding to the second workflow stage based on the current workflowstage indicating that the transaction object has been processed by atleast the first microservice and a different third microservice. Thefirst workflow stage and a fourth workflow stage may be independent,such that a third microservice retrieves the transaction object based onthe current workflow stage of the transaction object matching the fourthworkflow stage irrespective of whether the first microservice hasprocessed the transaction object.

The transaction details may be immutable and may not change while thetransaction object is on the streaming data platform. The processing, bythe first microservice, of the transaction object may comprise verifyinga value of the transaction details, addenda data, and/or transactionmetadata against at least one rule. Processing of the transaction objectby the first microservice may comprise verifying a value of thetransaction details, addenda data, and/or transaction metadata against awatchlist. Processing of the transaction object by the secondmicroservice may comprise determining that the transaction details,addenda data, and/or transaction metadata fail at least one rule,flagging the transaction object for further review, and holding thetransaction object in the second workflow stage pending the furtherreview. Updating the current workflow stage of the transaction object tothe third workflow stage may be based on determining that the furtherreview is completed. Flagging the transaction object for further reviewmay comprise flagging the transaction object for manual review by auser. Flagging the transaction object for further review may comprisesetting the current workflow stage of the transaction object to a fourthworkflow stage associated with a third microservice. Updating thecurrent workflow stage of the transaction object to the third workflowstage may be based on determining that processing by the thirdmicroservice is completed.

As examples, the transaction type of the transaction object may be awire type transaction. The workflow may comprise a plurality ofprocessing steps required to approve a wire transaction. The transactiontype of the transaction object may be an automated clearing house (ACH)type transaction. The workflow may comprise a plurality of processingsteps required to approve an ACH transaction. The transaction type ofthe transaction object may be a cashier check type transaction. Theworkflow may comprise a plurality of processing steps required toapprove a cashier check transaction. The first microservice may processthe transaction object to validate a routing number associated with thetransaction object. The second microservice may process the transactionobject to verify compliance with at least one regulatory requirementassociated with the transaction type. The transaction object may bereceived via an application programming interface (API).

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. The plurality of microservices may comprise atleast a first microservice and a second microservice. The first andsecond microservice may be automatically configured to watch fortransactions on the streaming data platform in corresponding workflowstages based on a plurality of workflows corresponding to a plurality oftransaction types. The memory may store instructions that, when executedby the at least one processor, cause the platform to receive atransaction object comprising transaction details and transactionmetadata. The transaction metadata may comprise an indication of aworkflow corresponding to a transaction type of the transaction objectand a current workflow stage of the transaction object. The workflowcorresponding to the transaction type may comprise a plurality ofprocessing steps required to approve a given transaction of thetransaction type. The instructions, when executed by the at least oneprocessor, may further cause the platform to add the transaction objectto the streaming data platform; update the current workflow stage of thetransaction object to a first workflow stage; and listen to, by thefirst microservice, the streaming data platform to retrieve transactionsmatching the first workflow stage. The first workflow stage may beassociated with the first microservice based on the workflowcorresponding to the transaction type. The instructions, when executedby the at least one processor, may further cause the platform toretrieve, by the first microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching the first workflow stage; process, by the first microservice,the transaction object to add, remove, or update addenda data associatedwith the transaction object; update the current workflow stage of thetransaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; andlisten to, by the second microservice, the streaming data platform toretrieve transactions matching the second workflow stage. The secondworkflow stage may be associated with the second microservice based onthe workflow corresponding to the transaction type. The instructions,when executed by the at least one processor, may further cause theplatform to retrieve, by the second microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the second workflow stage; process, by the secondmicroservice, the transaction object; update the current workflow stageof the transaction object to a third workflow stage based on completingprocessing, by the second microservice, of the transaction object;determine that the current workflow stage of the transaction objectindicates that the transaction object has completed processingcorresponding to the workflow; and remove the transaction object fromthe streaming data platform and output the transaction object and anindication that the transaction object has completed the processingcorresponding to the workflow.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; updating the currentworkflow stage of the transaction object to a first workflow stage; andlistening, by a first microservice, the streaming data platform toretrieve transactions matching the first workflow stage. The firstworkflow stage may be associated with the first microservice based onthe workflow corresponding to the transaction type. The steps mayfurther comprise retrieving, by the first microservice and from thestreaming data platform, the transaction object based on the currentworkflow stage matching the first workflow stage; processing, by thefirst microservice, the transaction object; and listening, by a secondmicroservice, the streaming data platform to retrieve transactionsmatching the first workflow stage. The first workflow stage may be alsoassociated with the second microservice based on the workflowcorresponding to the transaction type. The steps may further compriseretrieving, by the second microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching the first workflow stage; processing, by the secondmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice and the secondmicroservice, of the transaction object; and listening, by a thirdmicroservice, the streaming data platform to retrieve transactionsmatching the second workflow stage. The second workflow stage may beassociated with the third microservice based on the workflowcorresponding to the transaction type. The steps may further compriseretrieving, by the third microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching the second workflow stage; processing, by the thirdmicroservice, the transaction object; updating the current workflowstage of the transaction object to a third workflow stage based oncompleting processing, by the third microservice, of the transactionobject; determining that the current workflow stage of the transactionobject indicates that the transaction object has completed processingcorresponding to the workflow; and removing the transaction object fromthe streaming data platform and outputting the transaction object and anindication that the transaction object has completed the processingcorresponding to the workflow.

According to some aspects, a computer-implemented method may comprisesteps comprising receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject; and retrieving, by a second microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the second workflow stage. The second workflow stage maybe associated with the second microservice based on the workflowcorresponding to the transaction type. The steps may further compriseprocessing, by the second microservice, the transaction object; updatingthe current workflow stage of the transaction object to a third workflowstage based on completing processing, by the second microservice, of thetransaction object; determining that the current workflow stage of thetransaction object indicates that the transaction object has completedprocessing corresponding to the workflow; and removing the transactionobject from the streaming data platform and outputting the transactionobject and an indication that the transaction object has completed theprocessing corresponding to the workflow.

Configurator—Dynamic Microservice Configuration

One or more aspects described herein may provide for dynamicreconfiguration of the workflows and/or microservices. For example, aworkflow may be modified to change a progression of a transaction objectfrom one microservice to the next. This may be implemented by modifyingthe configuration of a microservice to look for a different currentworkflow stage on the streaming data platform. A microservice may bemodified to change processing logic and/or any other aspect controllinghow the microservice interacts with the streaming data platform and/ortransaction objects, or any other aspect of the microservice. Forexample, processing logic of the microservice may be changed to anupdated version to be used in processing future transactions.

A configuration interface may generate configuration transaction objectsthat cause the dynamic reconfiguration of the workflow and/ormicroservices. Configuration transaction objects may be added to the SDPwith a configuration workflow type, and the microservices may retrieveand process the configuration transaction objects. The configurationtransaction objects may operate such that a target microservice isreconfigured as a result of processing the configuration transactionobject, whether to look for transactions on a different workflow and/orworkflow stage, or to modify the processing logic applied to thetransactions retrieved by the microservice.

As discussed above, each defined workflow on transaction exchangeplatform 320 may accept a transaction as part of the transaction's“saga” through the transaction exchange platform. Through the workflow,the transaction may or may not undergo different processing steps, whereeach step may be provided by one or many microservices or vendorsystems. In this way, updating the “saga” that applies to themicroservices, integrated vendor systems and datasets, and the entiretransaction exchange ecosystem may be akin to an exercise inconfiguration control. Aspects described herein may allow configurationsto be loaded into the transaction exchange platform via the streamingdata platform, and may be used to update the entire transaction exchangeplatform, one or more components of the transaction exchange platform,and/or transactions on the platform.

Traditional methods for doing this may require that each element of theworkflow be updated, creating exponentially expanding complexity,downtime, and consequently interjecting risk to the transaction exchangeecosystem. Dynamic reconfiguration as described further herein may solvea problem of traditional deployments that interrupt the entire systemand require each component to be individually validated. It may alsointerject a level of control in the deployment by enabling any level ofcontrol from the level of remapping the system up to controlling whichcomponent gets transactions associated with different versions of thecorresponding workflow. Dynamic reconfiguration may also provide controlover the system so that configuration can work from the most tacticalsingle transaction (singleton) level up to the entire transactionexchange. Coupled with other tools, such as cloud-based resiliencytools, dynamic reconfiguration may provide a level of flexibility notpresent in other deployment approaches or solutions to simplifyingand/or mitigating the risk of a failed deployment.

The transaction exchange may exist in a space that includes numerouslegacy, vendor, and future state solutions. Dynamic reconfiguration mayprovide advantages in supporting partnering with vendors and thirdparties of any kind as an integration approach can be agreed on andbrought into the transaction exchange as a service controlled throughdynamic reconfiguration. Once integrated, similarly to the versioncontrol described herein, the integration service can be toggled on andoff easily through dynamic reconfiguration processes.

FIG. 6 illustrates a transaction processing system 600, similar to thatillustrated in FIG. 3A and sharing many like components. However,transaction processing system 600 includes configuration interface 660to provide dynamic reconfiguration of the workflows and/ormicroservices. Configuration interface 660 may push configurationtransaction objects to SDP 325 to cause re-configuration of a firstmicroservice 631 a (represented as first version 631 a, which may beupdated to second version 631 b). Due to dynamic reconfiguration,transaction objects may be modified to keep track of the workflowversion they should be processed under, as shown by example transactionobject 607.

Users managing transaction exchange platform 320 may determine todynamically reconfigure one or more aspects of the platform, such as bymodifying a workflow or causing a new version of a microservice to bedeployed. Reconfiguration may be prompted through other processes, suchas via a watchdog microservice as discussed further below with respectto FIG. 9 . Reconfiguration may be done to update and/or improvesoftware processes. Reconfiguration may also be done to address problemsthat arise during processing, such as when certain systems becomeunavailable or otherwise encounter problems. Reconfiguration may be doneas a new persistent configuration, or could be temporary pendingresolution of an issue. The reconfiguration may target any aspect of theplatform with desired granularity. For example, the reconfiguration mayapply to the entire platform, one or more microservices, and/or one ormore transactions, as appropriate. Workflows on transaction exchangeplatform 320 may also be reconfigured, which may be accomplished throughmodifying individual microservices to control the workflow type andworkflow stages that they watch for.

Configuration interface 660 may generate configuration transactionobjects that cause the dynamic reconfiguration of the workflow and/ormicroservices. Configuration transaction objects may be added to the SDPwith a configuration workflow type, and the microservices may retrieveand process the configuration transaction objects. Each microservice ontransaction exchange platform 320 may be configured to watch fortransaction objects having a configuration workflow type (e.g.,configuration transaction objects), and may have a correspondingworkflow stage similarly to that discussed above with respect to FIGS.3A and 4 .

A configuration transaction object may be configured such that, whenprocessed by a microservice, it causes reconfiguration of thatmicroservice. Microservices on the transaction exchange platform 320 maybe programmed to process configuration transaction objects and makesuitable changes to their parameters based on the processed objects. Forexample, a microservice may process configuration transaction objectcomprising instructions to update the workflow assigned to themicroservice to a second version of the workflow, e.g., ACH v. 2, andmay update a workflow stage assigned to the microservice.Reconfiguration of microservices can be used to update workflows to newversions, create new workflows, and/or modify existing workflows.Transactions requiring modified processing may be assigned tomodified/updated/other workflows to change their assigned processing.

Versioning may be used to control processing by appropriate workflows,and may facilitate reliable and accurate record keeping and playback. Bytracking which version of a workflow handles a transaction, thetransaction can be replayed using the same version at a later time aspart of an audit. To this end, microservices may maintain separateindications of each workflow and version handled by the microservice.Transactions may maintain transaction metadata indicating a versionvalue for the workflow applied to the transaction. Transactions may beassigned a current workflow value when added to the transaction exchangeplatform, and this may be maintained through the life of thetransaction. In some circumstances, the version may be changed later andthe transaction re-run through the new version of the workflow.

Examples of some types of changes that may be implemented throughdynamic reconfiguration will be discussed with references to FIGS.7A-7C.

FIG. 7A illustrates pushing a new configuration to one or more of themicroservices associated with example workflow 710, which may correspondto example wire transaction workflow 400. This new configuration maymodify the processing logic applied by one or more of the microservicescorresponding to the steps of workflow 400/710. Configuration interface660 may generate a configuration transaction object comprising the newconfiguration and push it to the SDP stream. The configurationtransaction object may cause update of the microservices mid-stream aspart of the flow within the transaction exchange platform on the SDP.Each microservice, as with transaction objects, may be configured towatch for configuration transaction objects associated with aconfiguration workflow and corresponding workflow stage. Themicroservices may retrieve matching configuration transaction objectsand process them to effect an update to their respective processinglogic. A microservice, transaction object, and/or the configurationmicroservice may maintain a new and prior version of theirconfigurations. This may allow for processing under an appropriateversion, and may facilitate a transition between versions as furtherdiscussed herein.

The mid-stream nature of the dynamic reconfiguration may help avoidsignificant interruptions and replayability problems posed by priorsolutions. As illustrated, transactions 20, 30, 31, 32, and 33 may be onthe SDP and already subject to processing by microservices in thecurrent version of the workflow. When a new configuration is pushed(such as version 6.0), the transactions pending on the SDP may continueto be processed according to the prior version that they started under(e.g., version 5.0). New transactions 34, 35, 36, and 37 may beprocessed under the new version (6.0). As described above, this may beeffected through transaction metadata tracking the workflow versionassociated with the transaction as well as by configuring themicroservices to utilize version metadata in retrieving transactionsfrom the SDP. For example, returning to FIG. 6 , microservice 631 a mayrepresent a first version of a microservice that looks for transactionsin a given workflow type that have a first version value at acorresponding first workflow stage. Microservice 631 b may represent asecond version of the microservice, and may look for transactions in thesame workflow type but having a second version value at the samecorresponding first workflow stage. In some implementations, the versionvalue may be combined with the workflow type rather than separate (e.g.,“ACHv1” and “ACHv2” as separate workflows rather than version values).

This procedure, pushing configuration transaction objects via the SDP,may provide additional advantages in that, when new components areadded, the configuration interface 660 can interject that new componentmid-stream so that it is enabled as a new route without updating theentire transaction exchange. This limits disruption to the local “new”component being added or changed while protecting the entire system forthe change. This may be advantageous as change remains one of the singlebiggest drivers of break events. It also enables on-the-fly updateswithout taking the entire system down into maintenance.

FIG. 7B illustrates a dynamic reconfiguration of a workflow process 720,such as when a component becomes unavailable due to breakage or otheradverse events. The dynamic reconfiguration may reconfigure the workflowto bypass problematic services and redirect the workflow to manualreview and/or other replacement processing steps. The reconfigurationmay avoid bottlenecks associated with microservices earlier in theworkflow breaking and preventing transactions from advancing to latermicroservices. Reconfiguration of workflows may be accomplished throughreconfiguring the microservices involved in the workflow to look fordifferent current workflow stages on the SDP.

For example, in reconfigured workflow process 720, which may be amodification of example wire transaction workflow 400, the dynamicreconfiguration may cause all wire transactions to be subject to theenhanced processing of step ‘C’ rather than the branching pathsdescribed above with respect to FIG. 4 . This may be due to enhancedsecurity concerns, problems with international wire processing, problemsat other components, etc. The reconfiguration of FIG. 7B may beaccomplished by configuration interface 660 pushing a configurationtransaction object to the SDP that is configured to cause themicroservices associated with workflow 400/720 to modify what workflowsand workflow stages they look for, as well as how they update thecurrent workflow once processing is completed. In particular, themodification shown in FIG. 7B could be effected by modifying themicroservice associated with step ‘D’ to not pull any transactions,while the microservice affiliated with step ‘C’ may pull alltransactions completed by step ‘B’; or step ‘B’ could be modified toupdate the current workflow of all processed transactions such that theyprogress to the enhanced verification of step ‘C’, for example.

Modifications to the workflow may be done in response to determiningconditions that indicate that modified workflow processing should beimplemented. The modifications may also be done in response to userchanges to a DAG representing the workflow. A user may modify the DAG todefine a new workflow/version and the configuration interface 660 maygenerate a suitable configuration transaction object and push it to theSDP to effect the change. The system may provide a graphical userinterface to facilitate users entering modifications to the DAGassociated with the workflow processing.

Reconfiguration of the workflows and/or microservices may be handled ina versioned manner, such that transactions on the SDP may be handledaccording to an appropriate and auditable version of the workflow. Whena new configuration version is pushed to the SDP for a given workflow,it may be added with a new version value. Transaction objects on thetransaction exchange platform may include, as part of their transactionmetadata, an indication of a current version value for the workflow atthe time they entered the transaction exchange platform. Themicroservices on the transaction exchange platform may be furtherconfigured to identify transaction objects having an appropriate currentworkflow stages based on the version value of the transaction object.Thus, transactions added under a first workflow version may reliably beprocessed under the first workflow version, while transaction addedafter a shift to a second workflow version may be processed using thenew, updated workflow version (and associated microservices andprocessing logic).

Thus, a first microservice in a first version 631 a may be originallyconfigured to watch for transactions associated with the first workflowthat have a first version value, while the first microservice in asecond version 631 b may be configured to watch for transactionsassociated with the first workflow that have a different second versionvalue. Transactions added to the transaction exchange platform may beadded having a first version value prior to reconfiguring the firstmicroservice. The first version of the first microservice 631 a mayretrieve transactions matching the first version value in acorresponding workflow/stage. Once a reconfiguration is pushed to theSDP, later transaction added to the SDP may be added having a secondversion value. The second version of the first microservice 631 b mayretrieve transaction matching the second version value in acorresponding workflow/stage. This may allow for reliable and replayableprocessing of transactions according to the appropriate version ofapproval workflows.

New workflow versions may be added as illustrated in FIG. 7C, throughworkflow 730. One flexible use of this approach is the ability togenerate a workflow designed to modify an individual transaction and/orgroup of transactions. Version 1 of the work flow, indicated by thesingle arrows, may be applied to general transaction objects of a giventransaction type. Version 2 of the workflow, indicated by the doublearrows, may be applied to problematic transactions subject to modifiedprocessing. The transaction exchange platform may support microservices,queuing, and manual workflows as part of being highly resilient,especially around high value workflows. As such, the dynamicconfiguration aspects may facilitate controlling a single transaction'spath through the platform enabling it to bypass steps normally requiredby the common workflow. A new workflow can be introduced to theecosystem with differentiating execution tied directly to a transaction.

As an example implementation, the following sample data illustrates howa workflow may change across versions of the workflow according to oneor more aspects:

Initial Configuration Version 1 {  “SecurityIdentifier”: “<<identifier >>”,  “ConfigurationVersion”: “1”,  “WorkflowStage”: [{  “A”: [{    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”],   “WorkflowStageCompleted”: [“INIT”]   }],   “B”: [{    “WorkflowType”:[“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”],    “WorkflowStageCompleted”:[“A”]   }],   “C”: [{    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”,“CONFIG”],    “WorkflowStageCompleted”: [“B”]   }],   “E”: [{   “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”],   “WorkflowStageCompleted”: [“B”]   }],   “F”: [{    “WorkflowType”:[“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”],    “WorkflowStageCompleted”:[“C”, “E”]   }],   “G”: [{    “WorkflowType”: [“WIRE”, “ACH”, “RTP”,“CHECK”, “CONFIG”],    “WorkflowStageCompleted”: [“F”]   }]  }] } PostConfiguration Update Version 2 {  “SecurityIdentifier”: “<<identifier >>”,  “ConfigurationVersion”: “2”,  “WorkflowStage”: [{  “A”: [{     “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”],   “WorkflowStageCompleted”: [“INIT”]   “B”: [{    “WorkflowType”:[“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”],    “WorkflowStageCompleted”:[“A”]   }],   “D”: [{    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”,“CONFIG”],    “WorkflowStageCompleted”: [“B”]   }],   “C”: [{   “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”],   “WorkflowStageCompleted”: [“D”]   }],   “F”: [{    “WorkflowType”:[“WIRE”, “ACH”, “RTP”, “CHECK”, “CONFIG”],    “WorkflowStageCompleted”:[“C”]   }];   “G”: [{    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”,“CONFIG”],    “WorkflowStageCompleted”: [“F”]   }]  }] }

Another aspect of dynamic reconfiguration may provide an eventconfiguration library. Configurations employed to process transactionshave certain characteristics may be stored for re-use in other settings,such as when those same characteristics are encountered again.Configurations that were pushed to resolve those transaction may be usedagain to facilitate handling of other similar transactions. For example,if manual or other review identifies a high risk transaction, a highrisk transaction configuration can be pushed to apply a high riskversion of the workflow to the high risk transaction. As a particularexample, consider when a transaction is associated with a merger of twocompanies. To facilitate the merger, transactions may be reconfigured tobypass standard workflows and feed through specialized microservicesconfigured to meet specific reporting needs of M&A transactions.

These configurations may be utilized manually, automatically, through ahybrid approach, and others. For example, machine learning may beemployed to recognize problem situations with transactions. The machinelearning system may flag a transaction to be reconfigured to follow aconfiguration of the configuration library that was previously employedon similar transactions. The system may be designed to self-optimize itsown configurations, employing approaches based on features such asshortest path, fastest time, most secure, guaranteed deliver, or anyother features desirable to customers.

FIG. 8 depicts a flowchart illustrating an example method 800 todynamically reconfigure a transaction exchange platform, such astransaction exchange platform 320. Method 800 may be performed by anysuitable computing device and/or combination of computing devices,referred to as the system implementing method 800.

At step 805, the configuration interface 660 may generate aconfiguration transaction object. The configuration transaction objectmay be configured to cause a reconfiguration of the transaction exchangeplatform, one or more workflows, one or more microservices, and/or oneor more transactions. The configuration interface 660 may receive arequest to generate the configuration transaction object from a userand/or other system processes, such as a watchdog microservice(discussed further below with respect to FIG. 9 ). The configurationtransaction object may comprise transaction details and transactionmetadata. The transaction metadata may indicate that the transactionobject has a configuration workflow type and a current workflow stage ofthe configuration transaction object. In some embodiments, the workflowtype of the configuration transaction object is a workflow that ismodified by the configuration transaction object, and other aspects ofthe configuration transaction object indicate to a processingmicroservice that it includes an update to the processing of themicroservice. The configuration transaction object may includeinstructions that, when processed by the microservice, cause themicroservice to be reconfigured. Reconfiguration may include modifyingwhich workflow/version/stage the microservice looks for on the SDP,and/or may include modifying the core processing logic employed by themicroservice.

At step 810, the configuration interface 660 may add the configurationtransaction object to the SDP, where it may await processing by firstmicroservice 820 and second microservice 830.

The configuration transaction object may be picked up by firstmicroservice 820 and second microservice 830 in a similar fashion tothat described above with respect to FIG. 5 . At steps 821 and 831,first and second microservices 820 and 830 may listen to the SDP toretrieve transactions matching their assigned workflow stages incorresponding workflow types. The configuration transaction objects mayhave a configuration workflow type, and the microservices may watch fora configuration workflow type object having the workflow stagecorresponding to the microservice. At steps 823 and 833, themicroservices may retrieve the configuration transaction object forprocessing.

At steps 825 and 835, the microservices may process the configurationtransaction object when it is in a corresponding workflow stage.Processing the configuration transaction object may cause themicroservice to be updated. For example, the configuration transactionobject may cause the microservice to update what workflow/version/stageit looks for on the SDP. As another example, processing theconfiguration transaction object may cause the microservice to updatethe core processing logic that it applies to transactions.

At steps 827 and 837, the microservices may update the current workflowstage of the configuration transaction object and, at steps 829 and 839,the microservices may push the updated configuration object back to theSDP. For example, microservice 820 may update the current workflow stageof the configuration object to indicate that microservice 820 hascompleted processing, and microservice 830 may be configured to look fortransaction objects that have a current workflow stage that indicatesthat microservice 820 completed its processing.

At step 840, the system may determine that the current workflow stage ofthe configuration transaction object indicates that the processingassociated with the configuration workflow has completed, and theconfiguration transaction object may be removed from the SDP.Notification may be provided to an entity that prompted thereconfiguration that it has been implemented, in some embodiments.

Thus, according to some aspects, a computer-implemented method maycomprise configuring a plurality of microservices on a streaming dataplatform to watch for transactions having a corresponding workflow stageassociated with a first workflow. The first workflow may correspond to atransaction type and may comprise a plurality of processing stepsrequired to approve a given transaction of the transaction type. Thesteps may further comprise generating a configuration transaction objectthat may be configured to cause reconfiguration of the first workflow bycausing reconfiguration of at least one microservice of the plurality ofmicroservices. The configuration transaction object may comprisetransaction metadata that indicates a configuration workflow and acurrent workflow stage of the configuration transaction object. Thesteps may further comprise adding the configuration transaction objectto the streaming data platform and updating the current workflow stageof the configuration transaction object to a first workflow stage. Themethod may comprise listening, by a first microservice of the pluralityof microservices, the streaming data platform to retrieve transactionsmatching the first workflow stage; retrieving, by the first microserviceand from the streaming data platform, the configuration transactionobject based on the current workflow stage matching the first workflowstage; processing, by the first microservice, the configurationtransaction object to reconfigure the first microservice; and updatingthe current workflow stage of the configuration transaction object to asecond workflow stage based on completing processing, by the firstmicroservice, of the configuration transaction object. The method mayalso comprise determining that the current workflow stage of theconfiguration transaction object indicates that the configurationtransaction object has completed processing corresponding to theconfiguration workflow, and removing the configuration transactionobject from the streaming data platform and outputting an indicationthat the configuration transaction object has completed the processingcorresponding to the configuration workflow.

Reconfiguring the first microservice may comprise reconfiguring thefirst microservice to watch for a different second workflow stage.Reconfiguring the first microservice may cause the first microservice toprocess transaction objects at a different stage of the plurality ofprocessing steps of the first workflow. Reconfiguring the firstmicroservice may comprise reconfiguring the first microservice to modifyat least one operation that the first microservice performs ontransaction objects associated with the first workflow. Reconfiguringthe first microservice may cause removal of at least one secondmicroservice from the first workflow. The first microservice may beoriginally configured to update completed transactions with a firstcompleted workflow stage. Reconfiguring the first microservice maycomprise reconfiguring the first microservice to update completedtransactions with a different completed workflow stage. Reconfiguringthe first microservice may cause transaction objects to bypass at leastone second microservice included in the first workflow. The firstmicroservice may be originally configured to watch for transactionsassociated with the first workflow that have a first version value. Thereconfigured first microservice may be configured to watch fortransactions associated with the first workflow that have a differentsecond version value.

The method may further comprise adding a first transaction object havinga first version value to the streaming data platform prior toreconfiguring the first microservice; retrieving, by the firstmicroservice and from the streaming data platform, the first transactionobject based on a current workflow stage of the first transactionmatching the first workflow stage; processing, by the firstmicroservice, the first transaction object based on an originalconfiguration of the first microservice based on the first versionvalue; adding a second transaction object having a different secondversion value to the streaming data platform subsequent to reconfiguringthe first microservice; retrieving, by the first microservice and fromthe streaming data platform, the second transaction object based on acurrent workflow stage of the second transaction matching the firstworkflow stage; and processing, by the first microservice, the secondtransaction object based on the reconfiguration of the firstmicroservice based on the second version value. The steps may furthercomprise adding a first transaction object to the streaming dataplatform; determining a current version of the first workflowimplemented on the streaming data platform; and updating a version valueof the first transaction object based on the current version. The firstmicroservice may process the first transaction object based on anoriginal configuration or a modified configuration based on the versionvalue.

The workflow corresponding to the transaction type may comprise adirected acyclic graph (DAG) indicating the plurality of processingsteps required to approve a given transaction of the transaction type.The first microservice may be automatically configured to watch fortransactions on the streaming data platform in the first workflow stagebased on the DAG. Generating the configuration transaction object may bein response to an update to at least one of the plurality of processingsteps indicated in the DAG. The steps may further comprise providing agraphical user interface to allow a user to update the at least one ofthe plurality of processing steps indicated in the DAG.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be automatically configured to watch for transactionson the streaming data platform in a corresponding workflow stage basedon a plurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingconfiguring the plurality of microservices on the streaming dataplatform to watch for transactions having a corresponding workflow stageassociated with a first workflow. The first workflow may correspond to atransaction type and comprises a plurality of processing steps requiredto approve a given transaction of the transaction type. The steps mayfurther comprise processing, by a first microservice, transactionobjects on the streaming data platform based on the configuration; andgenerating a configuration transaction object that may be configured tocause reconfiguration of the first workflow by causing reconfigurationof at least one of microservice of the plurality of microservices. Theconfiguration transaction object may comprise transaction metadata thatindicates a configuration workflow and a current workflow stage of theconfiguration transaction object. The steps may further comprise addingthe configuration transaction object to the streaming data platform;updating the current workflow stage of the configuration transactionobject to a first workflow stage; listening, by a first microservice ofthe plurality of microservices, the streaming data platform to retrievetransactions matching the first workflow stage; retrieving, by the firstmicroservice and from the streaming data platform, the configurationtransaction object based on the current workflow stage matching thefirst workflow stage; and processing, by the first microservice, theconfiguration transaction object to reconfigure the first microservice.Subsequent to processing the configuration transaction object, the firstmicroservice may process transaction objects on the streaming dataplatform based on the reconfiguration.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise configuring a first microservice on a streaming dataplatform to watch for transactions having a first workflow stageassociated with a first workflow corresponding to a transaction type.The first workflow may comprise a plurality of processing steps requiredto approve a given transaction of the transaction type. The steps mayfurther comprise configuring a second microservice on the streaming dataplatform to watch for transactions having a second workflow stageassociated with the first workflow; and generating a configurationtransaction object that may be configured to cause reconfiguration ofthe first workflow by causing reconfiguration of the first microserviceand the second microservice. The configuration transaction object maycomprise transaction metadata that indicates a configuration workflow,and a current workflow stage of the configuration transaction object.The steps may further comprise adding the configuration transactionobject to the streaming data platform; updating the current workflowstage of the configuration transaction object to the first workflowstage; listening, by the first microservice, the streaming data platformto retrieve transactions matching the first workflow stage; retrieving,by the first microservice and from the streaming data platform, theconfiguration transaction object based on the current workflow stagematching the first workflow stage; processing, by the firstmicroservice, the configuration transaction object to reconfigure thefirst microservice; updating the current workflow stage of theconfiguration transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the configurationtransaction object; listening, by the second microservice, the streamingdata platform to retrieve transactions matching the second workflowstage; retrieving, by the second microservice and from the streamingdata platform, the configuration transaction object based on the currentworkflow stage matching the second workflow stage; processing, by thesecond microservice, the configuration transaction object to reconfigurethe second microservice; updating the current workflow stage of theconfiguration transaction object to a third workflow stage based oncompleting processing, by the second microservice, of the transactionobject; determining that the current workflow stage of the configurationtransaction object indicates that the configuration transaction objecthas completed processing corresponding to the configuration workflow;and removing the configuration transaction object from the streamingdata platform and outputting an indication that the configurationtransaction object has completed the processing corresponding to theconfiguration workflow.

According to some aspects, a computer-implemented method may comprisesteps comprising configuring a plurality of microservices on a streamingdata platform to watch for transactions having a corresponding workflowstage associated with a first workflow. The first workflow maycorrespond to a transaction type and comprises a plurality of processingsteps required to approve a given transaction of the transaction type.The steps may further comprise generating a configuration transactionobject that may be configured to cause reconfiguration of the firstworkflow by causing reconfiguration of at least one microservice of theplurality of microservices. The configuration transaction object maycomprise transaction metadata that indicates: a configuration workflow,and a current workflow stage of the configuration transaction object.The steps may further comprise adding the configuration transactionobject to the streaming data platform; retrieving, by a firstmicroservice and from the streaming data platform, the configurationtransaction object based on the current workflow stage matching a firstworkflow stage associated with the first microservice; processing, bythe first microservice, the configuration transaction object toreconfigure the first microservice; and updating the current workflowstage of the configuration transaction object to a second workflow stagebased on completing processing, by the first microservice, of theconfiguration trans action object.

Chronos—Snapshot Microservice and Transaction Replay

Some aspects described herein may provide a snapshot microservice on thetransaction exchange platform, configured to maintain a record of thedata values of each transaction object as they progress through thecorresponding workflows. “Snapshot,” when used to refer to the snapshotmicroservice, may refer to the functionality of the snapshotmicroservice to track a transaction object's data values and each of itschanged states as an archival service. The snapshot microservice thusmay also be referred to as a payment transaction object changed statearchive, or Chronos. The snapshot microservice may create a snapshotrecord for new transaction objects and store a copy of the data of thetransaction object. As the transaction object progresses through theworkflow and is processed by the other microservices, the snapshotmicroservice can identify transaction objects that have their datachanged. The snapshot microservice can retrieve the changed objects andstore snapshot data tracking the change of the transaction object.

FIG. 9 illustrates a transaction processing system 900 that may besimilar to transaction processing systems 300 and/or 600 of FIGS. 3A and6 . Transaction processing system 900 may add, relative to systems 300and 600, snapshot microservice 970 and watchdog microservice 980. Thisdocument section focuses on snapshot microservice 970, while the nextdocument section focuses on watchdog microservice 980.

Snapshot microservice 970 may operate on transaction exchange platform320 to maintain a record of the data values of each transaction objecton the streaming data platform, and may track how the transactionobjects change during processing on the platform. Snapshot data may bestored in snapshot database 975, which may comprise on-disk storagecapable of effectively storing large volumes of data. Snapshotmicroservice 970 and snapshot database 975 may be configured to storedifferential snapshots of a transaction object. Snapshot microservice970 may store an original state of a transaction object when it is addedto the SDP, and may store information indicating each subsequent changeto the transaction object. Snapshot microservice may track data valuesassociated with each of the transaction details, transaction addendadata, and/or transaction metadata. In some embodiments however, thetransaction metadata may be additionally and/or alternatively tracked bywatchdog microservice 980.

The snapshot microservice 970 may be configured to identify and retrievetransaction objects added to SDP 325 in an initialization stage.Transaction objects may be added to the SDP 325 in an “init” orinitialization stage, indicating that none of the workflow steps haveyet been completed. In some implementations, the initialization stagemay be a separate stage that is marked completed prior to processing bya first microservice 331, or may be commensurate in scope with a firstworkflow stage associated with a first microservice 331 of the workflow.In some implementations, the initialization stage for the object may behandled as part of the processing by the APIs 311, 313 that receivetransactions to be added to the SDP 325, or otherwise handled alongsideworkflow processing by the respective microservices 331, 332, and 333.

Snapshot microservice 970 may store an initial snapshot of a transactionobject in the initialization stage, then update a current workflow stageof the transaction object to indicate that the initialization processinghas completed. This may comprise updating the current workflow stage ofthe transaction object to match a first workflow stage associated withmicroservice 331, which microservice 331 performs the first step of theworkflow. Alternatively, snapshot microservice 970 may treat transactionobjects in the first workflow stage as being subject to initialization(as new objects), and may determine that an initial, new snapshot shouldbe recorded in snapshot database 975.

Snapshot microservice 970 may be configured to listen to the SDP toretrieve all transaction objects having changed data. In someembodiments, this may comprise retrieving all transaction objects anddetermining whether there have been any changes. In other embodiments,it may comprise retrieving specifically the transaction objects thathave changed, whether based on determining that the data has changed ormerely that a workflow stage has advanced. Snapshot microservice 970 maydetermine a difference in the changed transaction object and storesnapshot information indicating the difference. The snapshot informationmay include metadata such as an associated timestamp, workflow stage,and/or any other suitable metadata to facilitate audit and potentialrollback of the transaction object and workflow processing.

These snapshots of the transaction object may be used to correctprocessing errors in the approval workflow, as a transaction object mayhave its data reverted back to an earlier state and its workflow stagereverted to an earlier stage. In this way, the transaction object may bemade to repeat an earlier step of the workflow and be subject tore-processing by a corresponding microservice (or, in some cases such asrepeated failures, a human operator). The snapshot microservice 970 mayregenerate a transaction object using the snapshot data corresponding tothe transaction object from an earlier time, prior to a point inprocessing that is subject to the rewind. In effect, snapshotmicroservice 970 may roll back the values of the transaction object toan earlier point in time. Then, the regenerated transaction object maybe put back on SDP 325 and will be picked up for re-processing by theearlier microservice. For example, if an error is determined to haveoccurred during processing of transaction object 307 by firstmicroservice 331, the snapshot microservice 970 may revert transactionobject 307 to state prior to processing by first microservice 331. Thefirst microservice 331 would have updated the stage of the transactionobject 307 to the second workflow stage when processing completed. Thesnapshot microservice 970 may revert the current workflow stage of thetransaction object 307 to the first workflow stage, so that when thetransaction object 307 is pushed back to the SDP 325 it will be pickedup for processing again by the first microservice 331.

A command to replay a transaction may be received by the snapshotmicroservice 970. For example, watchdog microservice 980 may determinethat processing by first microservice 331 completed abnormally, and maycommand snapshot microservice 970 to perform a replay. Other conditionsmay prompt a replay, such as an error state of a microservice or thetransaction exchange platform 320.

The snapshot microservice may track the total number of times that atransaction object is reverted/replayed on one or more microservices,and may flag a transaction as presenting problems requiring manual orother review when the number of replays exceeds a transaction or basedon other criteria. Replaying a transaction may cause update of atransaction replay count associated with the transaction, which may bestored as part of the transaction object's transaction metadata and/oras part of the snapshot information. If a threshold number of replaystake place, for example a configurable maximum of 3 replays at a singlestage of the workflow, the snapshot microservice 970 may flag thetransaction as having failed and/or requiring further review. Themaximum, which may be implemented as a threshold value, may beconfigured by a user and/or may be automatically configured by systemprocesses based on historical data, current system state, and otherperformance metrics. The transaction may be held in a workflow stagecorresponding to the microservice where processing failed, in someinstance. In other instances, a failed transaction may be routed toadditional processing, such as by a different workflow and/or otherparts of the same workflow, where it may be processed by othermicroservices.

When a replay occurs, the snapshot information may continue to track allsubsequent events as well as all events that had occurred already on thetransaction, even if they are subject to rewinding. Thus, the snapshotinformation may support a comparison during troubleshooting to assesswhich parts of the system led to errors in the workflow. Thisinformation may be archived to assist in troubleshooting and audits.Snapshot information related to error processing that is fixed viareplay may be deleted upon successful completion of the re-attempt.

The snapshot data may also support audit of the transactions, offering acomplete picture of how the transaction object changed while on thetransaction exchange platform. If desired as part of auditing results,the snapshot microservice 970 may replay an entire transaction snapshotby snapshot. This may be done in support of an audit or fortroubleshooting and analysis.

FIG. 10 depicts a flowchart illustrating an example method 1000 togenerate snapshot information tracking a transaction object on atransaction exchange platform, such as transaction exchange platform320. Method 1000 may be performed by any suitable computing deviceand/or combination of computing devices, referred to as the systemimplementing method 1000.

At step 1005, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

At step 1031, snapshot microservice 1030 may store an initial snapshotrecord for new transaction objects on the SDP. For example, snapshotmicroservice 1030 may listen to the SDP for transaction objects in theinitialization stage. Alternatively and/or additionally, snapshotmicroservice 1030 may listen to the SDP for all transaction objects, anddetermine which are new and should be stored as initial snapshotrecords.

At step 1033, snapshot microservice 1030 may update the current workflowstage of the transaction object to indicate completion of initializationprocessing by the snapshot microservice 1030. This may comprise updatingthe current workflow stage of the transaction object to be a workflowstage associated with a workflow microservice 1020. At step 1035,snapshot microservice 1030 may put the transaction object back to theSDP with the updated current workflow stage.

At step 1021, workflow microservice 1020 may listen to the SDP fortransactions having a current workflow stage assigned to themicroservice, and at step 1023 the workflow microservice may retrievethe matching transaction objects. At step 1025, workflow microservice1020 may process the transaction objects according to its respectiveprocessing logic, which may include updating, adding, removing, and/orotherwise changing values of the transaction details, addenda data,and/or transaction metadata associated with the transaction object. Atstep 1027, workflow microservice 1020 may update the transactionobject's current workflow stage to indicate completion of processing bymicroservice 1020 and, at step 1029, put the updated transaction objectback to the SDP.

At step 1037, snapshot microservice 1030 may listen to the SDP fortransactions and, at step 1039, determine transaction having changeddata. Snapshot microservice 1030, at step 1041, may record snapshot datacorresponding to the changed data as a result of processing by workflowmicroservices 1020. The snapshot microservice 1030 may, at step 1043,put the transaction object back to the SDP for further processing byworkflow microservices 1020.

FIG. 11 depicts a flowchart illustrating an example method 1100 toreplay a transaction (e.g., subject it to reprocessing) using a snapshotmicroservice on a transaction exchange platform, such as transactionexchange platform 320. Method 1100 may be performed by any suitablecomputing device and/or combination of computing devices, referred to asthe system implementing method 1100.

At step 1105, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

The transaction object may be processed by microservice 1120 in steps1121, 1123, 1125, 1127, and 1129 as described herein, for example insimilar fashion to that described with respect to FIG. 10 in steps 1021,1023, 1025, 1027, and 1029.

Snapshot microservice 1130 may record initial and changed snapshotinformation in steps 1131 and 1131, as described in greater detail abovewith respect to FIG. 10 in steps 1031, 1033, 1035, 1037, 1039, 1041, and1043.

At step 1135, snapshot microservice 1130 may receive a command to replaya workflow step for a transaction object. For example, a watchdogmicroservice may send snapshot microservice 1130 a command to replay thetransaction object in a first workflow stage.

At step 1137, snapshot microservice 1130 may use the stored snapshotinformation to roll back the transaction object to its state prior tothe point of replay. The transaction object may be made to repeat anearlier step of the workflow and be subject to re-processing by amicroservice to the workflow step indicated to be replayed. The snapshotmicroservice 1130 may regenerate a transaction object using the snapshotdata corresponding to the transaction object from an earlier time, priorto a point in processing that is subject to the rewind.

At step 1139, snapshot microservice 1130 may put the regeneratedtransaction object back on the SDP. Because the regenerated transactionobject has the earlier workflow stage, it will be picked up forre-processing by the earlier microservice.

Thus, according to some aspects, a computer-implemented method maycomprise steps comprising receiving a transaction object comprisingtransaction details, addenda data, and transaction metadata. Thetransaction metadata may comprise an indication of a workflowcorresponding to a transaction type of the transaction object, and acurrent workflow stage of the transaction object. The workflowcorresponding to the transaction type may comprise a plurality ofprocessing steps required to approve a given transaction of thetransaction type. The steps may further comprise adding the transactionobject to a streaming data platform. Adding the transaction object tothe streaming data platform may comprise setting the current workflowstage of the transaction object to an initialization stage. The stepsmay further comprise listening, by a snapshot microservice, thestreaming data platform to retrieve transactions matching theinitialization stage. The initialization stage may be associated withthe snapshot microservice. The steps may further comprise retrieving, bythe snapshot microservice and from the streaming data platform, thetransaction object based on the current workflow stage matching theinitialization stage; storing, by the snapshot microservice, snapshotdata corresponding to the transaction object; and updating the currentworkflow stage of the transaction object to a next workflow stage basedon completing storing, by the snapshot microservice, the snapshot datacorresponding to the transaction object. The method may compriseretrieving, by a first microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching a first workflow stage. The first workflow stage may beassociated with the first microservice based on the workflowcorresponding to the transaction type. The steps may further compriseprocessing, by the first microservice, the transaction object to modifythe addenda data. The method may comprise determining, by the snapshotmicroservice and via the streaming data platform, that at least onevalue associated with the addenda data of the transaction object haschanged after the transaction object has left the initialization stage,and storing, by the snapshot microservice, snapshot data correspondingto the changed at least one value associated with the addenda data.

Determining that the at least one value associated with the addenda dataof the transaction object has changed may comprise retrieving, by thesnapshot microservice and from the streaming data platform, thetransaction object. The steps may further comprise determining that theprocessing, by the first microservice, of the transaction object did notcomplete successfully, and causing the first microservice to repeatprocessing of the transaction object based on the snapshot datacorresponding to the transaction object from prior to the start of theprocessing by the first microservice. Causing the first microservice torepeat processing of the transaction object may comprise regenerating,by the snapshot microservice, the transaction object based on thesnapshot data corresponding to the transaction object from prior to thestart of the processing by the first microservice, and returning theregenerated transaction object to the streaming data platform. Thecurrent workflow stage of the regenerated transaction object may be setto the first workflow stage. The steps may further comprise determininga number of times that the transaction object has undergone processingby the first microservice and, in response to determining that thenumber of times that the transaction object has undergone processing bythe first microservice exceeds a threshold value, rejecting thetransaction object as having failed processing associated with the firstmicroservice. The steps may further comprise flagging the transactionobject for further review based on rejecting the transaction and holdingthe transaction object in the first workflow stage pending the furtherreview. Updating the current workflow stage of the transaction object toa second workflow stage may be based on determining that the furtherreview is completed. Flagging the transaction object for further reviewmay comprise flagging the transaction object for manual review by auser. Flagging the transaction object for further review may comprisecausing the transaction object to be processed by a third microservice.Updating the current workflow stage of the transaction object to thesecond workflow stage may be based on determining that processing by thethird microservice is completed. The snapshot microservice may recordsecond snapshot data corresponding to the transaction object from priorto causing the first microservice to repeat processing of thetransaction object. The second snapshot data may be maintained despitethe repeat processing of the transaction object.

The steps may further comprise determining, by the snapshot microserviceand via the streaming data platform, that at least one value associatedwith the transaction metadata has changed; retrieving, by the snapshotmicroservice and from the streaming data platform, the transactionobject based on determining that the at least one value has changed; andstoring, by the snapshot microservice, data corresponding to the changedat least one value associated with the transaction metadata. The nextworkflow stage may correspond to the first workflow stage associatedwith the first microservice. The initialization stage may correspond tothe first workflow stage. The snapshot microservice may generate atransaction history for the transaction object. The snapshotmicroservice may generate a transaction history for each transactionobject added to the streaming data platform. The snapshot microservicemay store snapshot data in an on-disk database.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details, addendadata, and transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform. Adding the transactionobject to the streaming data platform may comprise setting the currentworkflow stage of the transaction object to an initialization stage. Thesteps may further comprise listening, by a snapshot microservice, thestreaming data platform to retrieve transactions matching theinitialization stage. The initialization stage may be associated withthe snapshot microservice. The steps may further comprise retrieving, bythe snapshot microservice and from the streaming data platform, thetransaction object based on the current workflow stage matching theinitialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the transaction object, updating thecurrent workflow stage of the transaction object to a next workflowstage based on completing storing, by the snapshot microservice, thesnapshot data corresponding to the transaction object; and retrieving,by a first microservice and from the streaming data platform, thetransaction object based on the current workflow stage matching a firstworkflow stage. The first workflow stage may be associated with thefirst microservice based on the workflow corresponding to thetransaction type. The steps may further comprise processing, by thefirst microservice, the transaction object to modify the addenda data;determining, by the snapshot microservice and via the streaming dataplatform, that at least one value associated with the addenda data ofthe transaction object has changed after the transaction object has leftthe initialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the changed at least one value associatedwith the addenda data.

The steps may further comprise determining that the processing, by thefirst microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on the snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice. Causing the first microservice to repeat processingof the transaction object may comprise causing the transaction exchangeplatform to regenerate, by the snapshot microservice, the transactionobject based on the snapshot data corresponding to the transactionobject from prior to the start of the processing by the firstmicroservice; and return the regenerated transaction object to thestreaming data platform. A current workflow stage of the regeneratedtransaction object may be set to the first workflow stage. The snapshotmicroservice may generate a transaction history for each transactionobject added to the streaming data platform.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails, addenda data, and transaction metadata. The transactionmetadata may comprise an indication of a workflow corresponding to atransaction type of the transaction object, and a current workflow stageof the transaction object. The workflow corresponding to the transactiontype may comprise a plurality of processing steps required to approve agiven transaction of the transaction type. The steps may furthercomprise adding the transaction object to a streaming data platform.Adding the transaction object to the streaming data platform maycomprise setting the current workflow stage of the transaction object toan initialization stage. The steps may further comprise listening, by asnapshot microservice, the streaming data platform to retrievetransactions matching the initialization stage. The initialization stagemay be associated with the snapshot microservice. The steps may furthercomprise retrieving, by the snapshot microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the initialization stage; and storing, by the snapshotmicroservice, snapshot data corresponding to the transaction object,updating the current workflow stage of the transaction object to a nextworkflow stage based on completing storing, by the snapshotmicroservice, the snapshot data corresponding to the transaction object;and retrieving, by a first microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching a first workflow stage. The first workflow stage may beassociated with the first microservice based on the workflowcorresponding to the transaction type. The steps may further compriseprocessing, by the first microservice, the transaction object to modifythe addenda data; determining, by the snapshot microservice and via thestreaming data platform, that at least one value associated with theaddenda data of the transaction object has changed after the transactionobject has left the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the changed at least onevalue associated with the addenda data; determining that the processing,by the first microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on the snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice. Causing the first microservice to repeat processingof the transaction object may comprise regenerating, by the snapshotmicroservice, the transaction object based on the snapshot datacorresponding to the transaction object from prior to the start of theprocessing by the first microservice; and returning the regeneratedtransaction object to the streaming data platform. A current workflowstage of the regenerated transaction object may be set to the firstworkflow stage.

Arbiter—Watchdog Microservice for Tracking, Monitoring, and Remediation

Some aspects described herein may provide a watchdog microservice on thetransaction exchange platform, configured to track the progress oftransaction objects through their respective workflows. “Watchdog,” whenreferring to the watchdog microservice, may refer to the functionalityof the watchdog microservice to observe and archive the progress oftransaction objects on the transaction exchange platform, and enforcethe associated workflows. Thus the watchdog microservice may also bereferred to an observability and archive microservice, or Arbiter. Thewatchdog microservice may determine that a transaction object hascompleted the approval workflow based on the transaction objectcompleting each component step of the workflow, and may cause thecompleted transaction to be output from the transaction exchangeplatform. The watchdog microservice may also enforce the workflow,causing transactions to repeat and/or revisit problematic steps of theworkflow.

The watchdog microservice may track metrics and/or other statisticsassociated with the workflows, microservices, and/or transactions. Basedon the tracked workflow data, the watchdog microservice may be able toassess trends associated with a workflow, microservice, or transaction.The watchdog microservice may compare a metric and/or other statistic tothreshold performance values to determine when the workflow,microservice, or transaction is subject to abnormal or undesirableperformance complications. For example, the watchdog microservice coulddetermine that a particular microservice has a current averageprocessing time greater than a configured warning threshold, or outsidea typical range. Based on detecting abnormal or undesirable performanceof the workflow, microservice, or transaction, the watchdog microservicecan generate and/or implement a recommended corrective action. Examplecorrective actions may include causing a transaction to be replayed viaa snapshot microservice, and causing a workflow to be dynamicallyreconfigured using a configuration interface.

FIG. 9 , discussed above with respect to the snapshot microservice, alsodepicts watchdog microservice 980 and watchdog database 985. Watchdogmicroservice 980 may generate workflow tracking records for eachtransaction object on the transaction exchange platform 320, and maystore information indicating whether the transaction object completedeach step of the workflow along with timestamps and other suitablemetadata. The workflow tracking records may be stored in watchdogdatabase 985, which may comprise an in-memory database configured tosupport quick access and retrieval of records while on SDP 325.

The watchdog microservice 980 may serve as the judge (arbiter) indetermining when a transaction object has completed the workflowprocessing steps of its corresponding workflow. This is furtherdescribed with respect to FIG. 12 .

FIG. 12 depicts a flowchart illustrating an example method 1200 to trackworkflow progress and determine if a transaction has completed theworkflow on a transaction exchange platform, such as transactionexchange platform 320. Method 1200 may be performed by any suitablecomputing device and/or combination of computing devices, referred to asthe system implementing method 1200.

At step 1205, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

At step 1231, watchdog microservice 1230 may store an initial record fornew transaction objects on the SDP. Watchdog microservice 1230 mayidentify new transactions on the SDP, potentially as a result of theinitialization stage, and may generate new workflow tracking records forthe new transaction objects. Watchdog microservice 1230 may listen tothe SDP to retrieve new transactions as they are added. Additionallyand/or alternatively, watchdog microservice 1230 may listen to the SDPto retrieve all new transactions and determine which are new, as shownin step 1233.

Workflow microservices 1220 may process transaction objects on the SDPin the manners described above in detail. For example, illustrated steps1221, 1223, 1225, 1227, and 1229 may correspond to steps 1021, 1023,1025, 1027, and 1029 of FIG. 10 .

At step 1233, watchdog microservice 1230 may listen to the SDP fortransactions and, at step 1235, determine transaction objects having achanged workflow stage. In some embodiments, watchdog microservice 1230may listen to all transactions and determine which have changes. Inother embodiments, watchdog microservice 1230 may listen to the SDP torequest transaction that have changed.

At step 1237, watchdog microservice 1230 may record workflow trackingdata corresponding to the change in the workflow stage of thetransaction object. For example, watchdog microservice 1230 may update aworkflow tracking record associated with the transaction object toindicate it completed a workflow stage associated with a workflowmicroservice 1220. The watchdog microservice 1230 may further storeother metadata regarding the updated workflow stage, including atimestamp of the recorded change.

At step 1239, the watchdog microservice 1230 may determine whether thecurrent workflow stage of the transaction object (and/or the workflowtracking data) indicate that the transaction object has met therequisite steps of the workflow associated with the transaction type ofthe transaction objects. For example, the watchdog microservice 1230 mayassess whether the current workflow stage information of the transactionmetadata indicates completion of a series of steps that satisfy thecriteria of the workflow associated with a particular transaction typeof the transaction object.

At step 1241, the watchdog microservice 1230 may determine that theworkflow is not complete, and may proceed to step 1245 where thetransaction object is put back to the SDP after recording the workflowtracking information.

If, at step 1241, the watchdog microservice 1230 determines that theworkflow is complete, processing may proceed to step 1243 where thetransaction object is removed from the SDP of the transaction exchangeplatform and output as completed. For example, the transaction objectmay be updated with an indication that it completed the workflow and isapproved, and may be put to a public SDP 340 accessible to enterprisesystems and users 350.

Additionally and/or alternatively to the workflow completiondeterminations described above, the watchdog microservice 980/1230 mayenforce the individual steps of the workflow. The watchdog microservicemay assess whether a current workflow stage indicates a valid workflowstage under the restrictions of the workflow structure. If the currentworkflow stage of the transaction object is not valid, the watchdogmicroservice may cause the transaction object to be processed by one ormore appropriate microservices associated with the workflow, therebyenforcing the workflow. Working in conjunction with the snapshotmicroservice, the watchdog microservice may cause a transaction torepeat a step of the workflow by reverting the transaction object to anearlier state in response to detecting problems.

According to some aspects, the watchdog microservice may track metricsand/or other statistics associated with the workflows, microservices,and/or transactions. Based on the tracked workflow data, the watchdogmicroservice may be able to assess trends associated with a workflow,microservice, or transaction. The watchdog microservice may compare ametric and/or other statistic to threshold performance values todetermine when the workflow, microservice, or transaction is subject toabnormal or undesirable performance complications. This is describedfurther below with respect to FIG. 13 .

FIG. 13 depicts a flowchart illustrating an example method 1300 to trackworkflow progress and recommend corrective action based on performancemetrics on a transaction exchange platform, such as transaction exchangeplatform 320. Examples of performance metrics include, for example, howlong it takes a transaction to complete an associated workflow fromstart to finish. As will be discussed, performance metrics may bemeasured at any suitable level, for example per transaction, per groupof transaction, within a time frame, within a sample, and the like.Method 1300 may be performed by any suitable computing device and/orcombination of computing devices, referred to as the system implementingmethod 1300.

At step 1305, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

At step 1310, the watchdog microservice may track progress oftransaction objects on the SDP through the microservices and workflowsassociated with a transaction type of the transaction object, asdescribed above with respect to FIG. 12 .

At step 1315, the watchdog microservice may determine one or moreperformance metrics associated with the transaction exchange platform,one or more workflows, one or more microservices, types of transactions,groups of transactions, individual transactions, and/or any suitablegranularity. The watchdog microservice may record how long it takes atransaction to move through its corresponding workflow, frommicroservice to microservice. This time may be recorded against upperand/or lower control limits with a rolling time period. The time periodmay be taken into account and normalized against business cycles (forexample: weekends are different than work days and certain hours of thework day look very different). Other metrics may be considered besidesprocessing time, such as throughput (volume), error rates, approve/denyrates, paths taken in branching workflows, and/or any other suitablemetric.

Metrics may be tracked at any desired level of granularity. For example,the watchdog microservice may track how long transaction take toprogress through the ACH workflow, and may assess whether this is withinhistorical performance ranges. Similarly, the watchdog microservice maytrack how long a particular microservice takes to process transactionsover the last five minutes and determine when this rises above a warninglevel, which may indicate a problem with the microservice. The watchdogmicroservice may determine baseline performance metrics for thetransaction exchange platform, workflows, microservices, and the like.Current metrics may be compared to these baseline metrics to determineand address abnormal performance.

At step 1320, the watchdog microservice may determine at least onerecommended action based on the performance metrics. Many correctiveactions may be recommended by the watchdog microservice, which mayflexibly adapt and learn suitable processes for responding to abnormalsystem conditions. A common recommended corrective action may be tocommand replay of an earlier workflow stage for a transaction or groupof transactions. Working with the snapshot microservice, the watchdogmicroservice can cause a transaction object to revert to an earlierstate, where the reversion to the current workflow stage of thetransaction object would cause it to be processed again by anappropriate microservice. Where a particular microservice is showingperformance abnormalities across a range of transactions, the watchdogmicroservice may determine that the particular microservice is havingproblems and recommend a suitable corrective action. As an example, thewatchdog microservice may determine that a dynamic reconfiguration toimplement alternate processing workflows, addressing the issuespresented by the particular microservice, represents a suitablecorrective action. The watchdog microservice may coordinate with theconfiguration interface to effect a reconfiguration of the workflow andthe corresponding microservices, potentially temporarily. In someimplementations, dynamic reconfiguration of a workflow, microservice, ortransaction may be recommended and implemented once successive replaysthrough the snapshot microservice have failed. Such reconfiguration mayaddress patterns of failure that become apparent from repeat errors fromthe microservices/workflows.

The watchdog microservice may implement other corrective actions aswell. For example, the watchdog microservice may utilize machinelearning techniques to self-optimize the workflows based on any suitablefeature, such as enhancing actions (rather than corrective action),security lockdown against intrusions, speed throughput, prioritizedrouting, restart, and most any other incident, administrative, ormanagement handling. The watchdog microservice provides a usefulinterface and allows machine learning collector agents to be deployed onthe transaction exchange platform to gather system state information foruse in optimizing and managing the transaction exchange platform. Othermetrics in addition to performance, security, resiliency,responsiveness, robustness, visibility, etc. may be considered by thewatchdog microservice, and the flexibility and comprehensive scope ofthe watchdog microservices may enable powerful management of thetransaction exchange platform.

At step 1325, the watchdog microservice may cause the recommended actionto be implemented. For example, the watchdog microservice may commandthe snapshot microservice to replay a workflow stage for the transactionobject. As another example, the watchdog microservice may command theconfiguration interface to dynamically reconfigure one or more workflowsand/or microservices based on the performance metric.

Subsequent to implementing the corrective action, the watchdogmicroservice may determine that successful processing is completed instep 1330. Or the watchdog microservice may determine that processinghas failed in step 1340, and may output the transaction for furtherreview (manually and/or automatically), and may generate anotherrecommended action, at step 1345.

According to some aspects, and as discussed above, the watchdogmicroservice may recommend as a corrective action replay of an earlierworkflow stage for a transaction or group of transactions. Working withthe snapshot microservice, the watchdog microservice can cause atransaction object to revert to an earlier state, where the reversion tothe current workflow stage of the transaction object would cause it tobe processed again by an appropriate microservice. This is describedfurther below with respect to FIG. 14 .

FIG. 14 depicts a flowchart illustrating an example method 1400 to trackperformance metrics and determine to replay a transaction on atransaction exchange platform, such as transaction exchange platform320. Method 1400 may be performed by any suitable computing deviceand/or combination of computing devices, referred to as the systemimplementing method 1400. FIG. 14 may combine aspects of FIGS. 11 and 13, as explained further below.

At step 1405, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage. At step 1421, watchdogmicroservice 1420 may track program on the SDP of transaction objectsthrough microservice and workflows, as described with respect to FIG. 12above.

At step 1423, watchdog microservice 1420 may determine that atransaction object should replay a workflow stage. For example, asdiscussed above with respect to FIG. 13 , the watchdog microservice maydetermine that a transaction object did not correctly complete theworkflow step and/or that the microservice associated with the step isexperiencing abnormal performance issues. At step 1425, the watchdogmicroservice 1420 may command snapshot microservice 1430 to replay thetransaction object at the earlier workflow stage.

Snapshot microservice 1430 may store snapshot data records fortransaction objects on the SDP in steps 1431 and 1433, as discussedabove in FIGS. 10 and 11 . At step 1435, snapshot microservice 1430 mayreceive the command to replay the workflow step for the transactionobject from the watchdog microservice 1420. Snapshot microservice mayrollback the transaction object and reinject it to the SDP at steps 1437and 1439, in the manner described above with respect to FIG. 11 .

At step 1441, watchdog microservice 1420 may determine if the replayedworkflow stage was processed successfully. If it processed successful,processing may proceed to step 1443 where the transaction workflowcontinues.

If, at step 1441, watchdog microservice 1420 determines that processingdid not complete successfully, watchdog microservice 1420 may determinewhether a maximum number of rollbacks have been attempted at step 1445.The snapshot microservice 1430 and/or watchdog microservice 1420 maymaintain a counter of the number of rollback/replay attempts. The numberof rollback/replay attempts is less than a configurable threshold, thenprocessing may return to step 1425 where watchdog microservice 1420again commands snapshot microservice 1430 to replay the transaction.

If, at step 1445, watchdog microservice 1420 determines that a maximumnumber of replay attempts have already occurred, then watchdogmicroservice may determine a failure of the transaction to progressthrough the workflow stage at step 1447. At step 1449 the watchdogmicroservice 1420 may determine a further recommended action, such astriggering a dynamic reconfiguration of the work follow. This is shownfurther in FIG. 15 .

FIG. 15 depicts a flowchart illustrating an example method 1500 to trackperformance metrics and determine to replay a transaction on atransaction exchange platform, such as transaction exchange platform320. Method 1500 may be performed by any suitable computing deviceand/or combination of computing devices, referred to as the systemimplementing method 1500. FIG. 15 may combine aspects of FIGS. 11-14 ,as explained further below.

At step 1505, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage. At step 1521, watchdogmicroservice 1520 may track program on the SDP of transaction objectsthrough microservice and workflows, as described with respect to FIG. 12above.

At step 1522, the watchdog microservice may determine that a transactionobject should have a particular workflow stage replayed, and may orderthe snapshot microservice to replay the transaction as described in FIG.14 . Step 1522 may be optional, as watchdog microservice 1520 maydetermine to command dynamic reconfiguration even in the absence of areplayed transaction.

At step 1523, the watchdog microservice may determine that thetransaction exchange platform, one or more workflows, one or moremicroservices, or any other component should be modified. As discussedfurther above with respect to FIG. 13 , the watchdog microservice maymake this determination based on tracking one or more performancemetrics associated with the transaction exchange platform and/or any ofits components.

At step 1525, the watchdog microservice 1520 may command theconfiguration interface 1530 to reconfigure one or more microservices(and/or workflows, and/or any other component of the transactionexchange platform).

At step 1531, configuration interface 1530 may receive the command toreconfigure the microservices of the workflow, and may proceed throughsteps 1533 and 1535 to generate a configuration transaction object thatis pushed to the SDP to effect the desired reconfiguration, as describedabove with respect to FIG. 8 .

At step 1527, the watchdog microservice 1520 may command the snapshotmicroservice to replay the transaction object using the reconfiguredworkflow, if a particular transaction and/or group of transactions weresubject to erroneous and/or failed processing on the originalconfiguration.

At step 1529, the watchdog microservice 1520 may evaluate performance ofthe reconfigured workflow and continue to evaluate performance metricsassociated with aspects of the transaction exchange platform.

Thus, according to some aspects, a computer-implemented method maycomprise receiving a transaction object comprising transaction detailsand transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object and updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject. In response to determining, by a watchdog microservice and viathe streaming data platform, that the current workflow stage of thetransaction object has changed, the method may comprise: retrieving, bythe watchdog microservice and from the streaming data platform, thetransaction object based on determining that the current workflow stagehas changed and storing, by the watchdog microservice, workflow trackingdata corresponding to the transaction object and the changed currentworkflow stage.

The steps may further comprise determining, by the watchdogmicroservice, that the stored workflow tracking data corresponding tothe transaction object indicates that the transaction object completedeach stage of the workflow corresponding to the transaction type and, inresponse to determining that the stored workflow tracking data indicatesthat the transaction object completed each stage of the workflowcorresponding to the transaction type, removing the transaction objectfrom the streaming data platform and outputting the transaction objectand an indication that the transaction object has completed theprocessing corresponding to the workflow. The current workflow stage ofthe transaction object may comprise a data structure indicatingcompletion status of each respective step of a plurality of processingsteps associated with the workflow. The steps may further comprise, inresponse to the determining that the current workflow stage of thetransaction object has changed, determining, by the watchdogmicroservice, whether the current workflow stage of the transactionobject is valid based on the workflow associated with the transactiontype and, in response to determining that the current workflow stage ofthe transaction object is not valid, causing, by the watchdogmicroservice, the transaction object to be processed by one or moremicroservices associated with the workflow. The watchdog microservicemay store workflow tracking data in an in-memory database. The workflowtracking data may comprise a timestamp and an indication of the changeto the current workflow stage of the transaction object. The steps mayfurther comprise determining, by the watchdog microservice and based onthe workflow tracking data, at least one performance metric associatedwith the first microservice. The at least one performance metric maycorrespond to a single transaction object. The at least one performancemetric may correspond to a group of transaction objects over a period oftime. The steps may further comprise determining, by the watchdogmicroservice, that the at least one performance metric associated withthe first microservice fails to satisfy at least one thresholdperformance value; and performing at least one action based ondetermining that the at least one performance metric fails to satisfythe at least one threshold performance value. The steps may furthercomprise determining, by the watchdog microservice and based on theworkflow tracking data, at least one performance metric associated withthe workflow.

The steps may further comprise determining, by the watchdogmicroservice, that the at least one performance metric associated withthe workflow fails to satisfy at least one threshold performance value;and performing at least one action based on determining that the atleast one performance metric fails to satisfy the at least one thresholdperformance value. The steps may further comprise determining, by thewatchdog microservice and based on the workflow tracking data, at leastone baseline metric associated with the first microservice. The baselinemetric may correspond to processing performance by the firstmicroservice on a set of transaction objects over a period of time. Thesteps may further comprise determining, by the watchdog microservice andbased on the workflow tracking data, at least one performance metricassociated with a first transaction object processed by the firstmicroservice; determining that the at least one performance metricassociated with the first transaction object fails to satisfy athreshold relationship to the at least one baseline metric; andgenerating a recommended action to be taken on the first transactionobject. The recommended action may comprise causing the firsttransaction object to be re-processed by the first microservice. Therecommended action may comprise re-routing the first transaction objectto be processed by another microservice. The recommended action maycomprise changing the transaction type of the first transaction object.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details andtransaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject; in response to determining, by a watchdog microservice and viathe streaming data platform, that the current workflow stage of thetransaction object has changed: retrieving, by the watchdog microserviceand from the streaming data platform, the transaction object based ondetermining that the current workflow stage has changed; and storing, bythe watchdog microservice, workflow tracking data corresponding to thetransaction object and the changed current workflow stage; determining,by the watchdog microservice, that the stored workflow tracking datacorresponding to the transaction object indicates that the transactionobject completed each stage of the workflow corresponding to thetransaction type; and in response to determining that the storedworkflow tracking data indicates that the transaction object completedeach stage of the workflow corresponding to the transaction type,removing the transaction object from the streaming data platform andoutput the transaction object and an indication that the transactionobject has completed the processing corresponding to the workflow. Thesteps may further comprise determining, by the watchdog microservice andbased on the workflow tracking data, at least one performance metricassociated with the first microservice. The steps may further comprisedetermining, by the watchdog microservice, that the at least oneperformance metric associated with the first microservice fails tosatisfy at least one threshold performance value; and generating arecommended action based on determining that the at least oneperformance metric fails to satisfy the at least one thresholdperformance value.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject; in response to determining, by a watchdog microservice and viathe streaming data platform, that the current workflow stage of thetransaction object has changed: retrieving, by the watchdog microserviceand from the streaming data platform, the transaction object based ondetermining that the current workflow stage has changed; and storing, bythe watchdog microservice, workflow tracking data corresponding to thetransaction object and the changed current workflow stage; determining,by the watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with the first microservice; andgenerating a graphic user interface display corresponding to the firstmicroservice and comprising the at least one performance metric.

And according to some aspects, a computer-implemented method maycomprise receiving a transaction object comprising transaction detailsand transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by afirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and inresponse to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on snapshot data corresponding to thetransaction object captured by a snapshot microservice.

The steps may further comprise listening, by the snapshot microservice,the streaming data platform to retrieve transactions matching aninitialization stage. Transactions may be added to the streaming dataplatform in the initialization stage. The initialization stage may beassociated with the snapshot microservice. The steps may furthercomprise retrieving, by the snapshot microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the transaction object;determining, by the snapshot microservice and via the streaming dataplatform, that at least one value associated with addenda data of thetransaction object has changed after the transaction object has left theinitialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the changed at least one value associatedwith the addenda data. The snapshot microservice may cause the firstmicroservice to repeat processing of the transaction object based on thesnapshot data corresponding to the transaction object from prior to thestart of the processing by the first microservice. Causing the firstmicroservice to repeat processing of the transaction object may compriseregenerating, by the snapshot microservice, the transaction object basedon snapshot data corresponding to the transaction object from prior tothe start of the processing by the first microservice; and returning theregenerated transaction object to the streaming data platform. Thecurrent workflow stage of the regenerated transaction object may be setto the first workflow stage. The steps may further comprise determining,by the watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with the first microservice.Determining that the processing, by the first microservice, of thetransaction object did not complete successfully may be based ondetermining that the at least one performance metric associated with thefirst microservice fails to satisfy at least one performance thresholdvalue. The at least one performance metric may correspond to a singletransaction object. The at least one performance metric may correspondto a group of transaction objects over a period of time. The steps mayfurther comprise determining, by the watchdog microservice and based onthe workflow tracking data, at least one baseline metric associated withthe first microservice. The baseline metric may correspond to processingperformance by the first microservice on a set of transaction objectsover a period of time. The steps may further comprise determining, bythe watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with a first transaction objectprocessed by the first microservice. Determining that the processing, bythe first microservice, of the transaction object did not completesuccessfully may be based on determining that the at least oneperformance metric associated with the first transaction object fails tosatisfy a threshold relationship to the at least one baseline metric.The steps may further comprise determining a number of times that thetransaction object has undergone processing by the first microservice;in response to determining that the number of times that the transactionobject has undergone processing by the first microservice exceeds athreshold value, rejecting the transaction object as having failedprocessing associated with the first microservice; and determining acorrective action for the transaction object based on rejecting thetransaction object. The corrective action may comprise re-routing thefirst transaction object to be processed by another microservice. Thecorrective action may comprise changing the transaction type of thetransaction object. The corrective action may comprise changing theindication of the workflow corresponding to the transaction type of thetransaction object.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details, addendadata, and transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and listening, by asnapshot microservice, the streaming data platform to retrievetransactions matching an initialization stage. Transactions may be addedto the streaming data platform in the initialization stage. Theinitialization stage may be associated with the snapshot microservice.The steps may further comprise retrieving, by the snapshot microserviceand from the streaming data platform, the transaction object based onthe current workflow stage matching the initialization stage; storing,by the snapshot microservice, snapshot data corresponding to thetransaction object; and processing, by a first microservice, thetransaction object on the streaming data platform based on the currentworkflow stage matching a first workflow stage. The first workflow stagemay be associated with the first microservice based on the workflowcorresponding to the transaction type. The steps may further comprisedetermining, by the snapshot microservice and via the streaming dataplatform, that at least one value associated with the addenda data ofthe transaction object has changed after the transaction object has leftthe initialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the changed at least one value associatedwith the addenda data; updating the current workflow stage of thetransaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and,in response to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on the snapshot data corresponding to thetransaction object captured by a snapshot microservice.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails, addenda data, and transaction metadata. The transactionmetadata may comprise an indication of a workflow corresponding to atransaction type of the transaction object, and a current workflow stageof the transaction object. The workflow corresponding to the transactiontype may comprise a plurality of processing steps required to approve agiven transaction of the transaction type. The steps may furthercomprise adding the transaction object to a streaming data platform. Thetransaction object may be added to the streaming data platform in aninitialization stage. The steps may further comprise listening, by thesnapshot microservice, the streaming data platform to retrievetransactions matching the initialization stage. The initialization stagemay be associated with the snapshot microservice. The steps may furthercomprise retrieving, by the snapshot microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the transaction object; andprocessing, by the first microservice, the transaction object on thestreaming data platform based on the current workflow stage matching afirst workflow stage. The first workflow stage may be associated withthe first microservice based on the workflow corresponding to thetransaction type. The steps may further comprise determining, by thesnapshot microservice and via the streaming data platform, that at leastone value associated with addenda data of the transaction object haschanged after the transaction object has left the initialization stage;storing, by the snapshot microservice, snapshot data corresponding tothe changed at least one value associated with the addenda data;updating the current workflow stage of the transaction object to asecond workflow stage based on completing processing, by the firstmicroservice, of the transaction object; and in response to determining,by a watchdog microservice and via the streaming data platform, that thecurrent workflow stage of the transaction object has changed, storingworkflow tracking data corresponding to the transaction object and thechanged current workflow stage; determining, by the watchdogmicroservice, that the processing, by the first microservice, of thetransaction object did not complete successfully; and causing the firstmicroservice to repeat processing of the transaction object based onsnapshot data corresponding to the transaction object captured by asnapshot microservice by: regenerating, by the snapshot microservice,the transaction object based on snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice; and returning the regenerated transaction object tothe streaming data platform. The current workflow stage of theregenerated transaction object may be set to the first workflow stage.The steps may further comprise determining, by the watchdog microserviceand based on the workflow tracking data, at least one baseline metricassociated with the first microservice. The baseline metric maycorrespond to processing performance by the first microservice on a setof transaction objects over a period of time. The steps may furthercomprise determining, by the watchdog microservice and based on theworkflow tracking data, at least one performance metric associated withthe first transaction object processed by the first microservice.Determining that the processing, by the first microservice, of thetransaction object did not complete successfully may be based ondetermining that the at least one performance metric associated with thesingle transaction objects fails to satisfy a threshold relationship tothe at least one baseline metric.

According to some aspects, a computer-implemented method may comprisesteps comprising receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by afirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and,in response to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and reconfiguring the first microservice or a relatedsecond microservice based on determining that the processing, by thefirst microservice, of the transaction object did not completesuccessfully. The steps may further comprise causing the firstmicroservice to repeat processing of the transaction object based onsnapshot data corresponding to the transaction object captured by asnapshot microservice; and determining that the repeat processing of thetransaction object also did not complete successfully. Reconfiguring thefirst microservice or the related second microservice may be based ondetermining that the repeat processing of the transaction object failed.Reconfiguring the first microservice or a related second microservicemay comprise generating a configuration transaction object that may beconfigured to cause reconfiguration of the first workflow by causingreconfiguration of the first microservice. The configuration transactionobject may comprise transaction metadata that indicates a configurationworkflow and a current workflow stage of the configuration transactionobject. The steps may further comprise adding the configurationtransaction object to the streaming data platform; updating the currentworkflow stage of the configuration transaction object to the firstworkflow stage; retrieving, by the first microservice and from thestreaming data platform, the configuration transaction object based onthe current workflow stage matching the first workflow stage; andprocessing, by the first microservice, the configuration transactionobject to reconfigure the first microservice. Reconfiguring the firstmicroservice or the related second microservice may cause transactionobjects associated with the workflow to be dynamically re-routed.Reconfiguring the first microservice or the related second microservicemay comprise reconfiguring the first microservice to modify at least oneoperation that the first microservice performs on transaction objectsassociated with the workflow. Reconfiguring the first microservice orthe related second microservice may comprise reconfiguring the relatedsecond microservice to cause removal of the first microservice from theworkflow. The second related microservice may be a predecessormicroservice that proceeds the first microservice in the workflow. Thesteps may further comprise determining, by the watchdog microservice, atleast one performance metric associated with the first micro service.Determining that the processing, by the first microservice, of thetransaction object did not complete successfully may be based ondetermining that the at least one performance metric associated with thefirst microservice fails to satisfy at least one threshold performancevalue. The steps may further comprise determining, by the watchdogmicroservice and based on the workflow tracking data, at least oneperformance metric associated with the workflow. Determining that theprocessing, by the first microservice, of the transaction object did notcomplete successfully may be based on determining that the at least oneperformance metric associated with the workflow fails to satisfy atleast one threshold performance value.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details andtransaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by thefirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and inresponse to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and reconfigure the first microservice based ondetermining that the processing, by the first microservice, of thetransaction object did not complete successfully by generating aconfiguration transaction object that may be configured to causereconfiguration of the first microservice and adding the configurationtransaction object to the streaming data platform. The steps may furthercomprise causing the first microservice to repeat processing of thetransaction object based on snapshot data corresponding to thetransaction object captured by a snapshot microservice; and determiningthat the repeat processing of the transaction object also did notcomplete successfully. Reconfiguring the first microservice may be basedon determining that the repeat processing of the transaction objectfailed. Reconfiguring the first microservice may cause transactionobjects associated with the workflow to be dynamically re-routed.Reconfiguring the first microservice may comprise reconfiguring thefirst microservice to modify at least one operation that the firstmicroservice performs on transaction objects associated with theworkflow. Reconfiguring the first microservice may comprisereconfiguring a related second microservice to cause the removal of thefirst microservice from the workflow. The second related microservicemay be a predecessor microservice that proceeds the first microservicein the workflow. The steps may further comprise determining, by thewatchdog microservice, at least one performance metric associated withthe first micro service. Determining that the processing, by the firstmicroservice, of the transaction object did not complete successfullymay be based on determining that the at least one performance metricassociated with the first microservice fails to satisfy at least onethreshold performance value. The steps may further comprise determining,by the watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with the workflow. Determiningthat the processing, by the first microservice, of the transactionobject did not complete successfully may be based on determining thatthe at least one performance metric associated with the workflow failsto satisfy at least one threshold performance value.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by afirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and,in response to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; causing the first microservice to repeat processing of thetransaction object based on snapshot data corresponding to thetransaction object captured by a snapshot microservice; and determiningthat the repeat processing of the transaction object also did notcomplete successfully; and reconfiguring the first microservice or arelated second microservice, based on determining that the repeatprocessing of the transaction object also did not complete successfully.Reconfiguring the first microservice may comprise generating aconfiguration transaction object that may be configured to causereconfiguration of the first workflow by causing reconfiguration of thefirst microservice. The configuration transaction object may comprisetransaction metadata that indicates a configuration workflow, and acurrent workflow stage of the configuration transaction object.Reconfiguring the first microservice may further comprise adding theconfiguration transaction object to the streaming data platform;updating the current workflow stage of the configuration transactionobject to the first workflow stage; retrieving, by the firstmicroservice and from the streaming data platform, the configurationtransaction object based on the current workflow stage matching thefirst workflow stage; and processing, by the first microservice, theconfiguration transaction object to reconfigure the first microservice.Reconfiguring the first microservice or the related second microservicemay cause transaction objects associated with the workflow to bedynamically re-routed.

Baahubali—Classification Microservice for Changing a Workflow

Some aspects described herein may provide a classification microserviceon the transaction exchange platform. Each transaction object receivedby the transaction exchange platform may be associated with a paymenttype with a corresponding workflow (e.g., rail). As noted above, aworkflow indicates the steps necessary to process a transaction on thetransaction exchange platform before it is ready for output todownstream processors. The classification microservice described hereinmay review (e.g., analyze) transaction objects as they are received todetermine whether the transaction object may be processed according toan alternative workflow that may be more effective. Additionally oralternatively, the classification microservice may review (e.g.,analyze) transaction objects that have not been processed correctly(e.g., has errors, failed, etc.) to determine whether those transactionobjects may be processed using a different workflow. When theclassification microservice determines that the transaction object maybe processed via an alternative (e.g., different) workflow, theclassification microservice may re-classify (e.g., change) the workflowof the transaction object to the alternative workflow. The transactionobject may then be processed according to the alternative workflow. Bychanging the workflow associated with a transaction object, theclassification microservice may improve the performance of thetransaction exchange platform by reducing the number of processingcycles required to process the transaction object. This may increase thespeed with which transaction objects are processed, reduce the costassociated with processing the transaction object, and/or improve thescalability of each workflow.

FIG. 16 illustrates a transaction processing system 1600 that may besimilar to transaction processing systems 300 and/or 600 of FIGS. 3A and6 . Transaction processing system 1600 may add, relative to systems 300and/or 600, classification microservice 1670. This document sectionfocuses on classification microservice 1670.

Classification microservice 1670 may operate on transaction exchangeplatform 320 to determine whether a transaction object includesinformation that would allow the transaction object to be processedusing an alternative workflow and/or a secondary workflow. Theclassification microservice may allow one or more machine learningcollector agents to be deployed on the transaction exchange platform togather information about transaction objects for use in optimizingperformance of the transaction exchange platform by re-classifyingtransaction objects to alternative (e.g., different) workflows. Theclassification microservice 1670 (e.g., the one or more collectoragents) may use one or more machine-learning models to analyze and/orprocess the transaction object 1607 and determine whether thetransaction object 1607 can be processed via an alternative workflowand/or secondary workflow. The one or more machine learning models mayinclude one or more recurrent neural network models (RNN), convolutionalneural network models (CNN), and/or support-vector networks. Further,the one or more machine-learning models may leverage one or moretechniques including induction of decision trees, random forests,bootstrap aggregating, k-means clustering, k-nearest neighbors (k-NN),k-medoids clustering, regression, Bayesian networks, relevance vectormachine (RVM), support vector machines (SVM), generative adversarialnetworks (GAN), and the like. The present disclosure may utilize otherstatistical analysis methods, which may include multivariate orunivariate statistical analysis. The one or more machine-learning modelsmay be configured and/or trained to receive an input comprising thetransaction object 1607. The one or more machine-learning models maythen determine whether the associated transaction should be processedusing an alternative or secondary workflow. Further, the one or moremachine-learning models may determine the type of workflow or workflowsteps that should be used to process the transaction object 1607. Forexample, if the original workflow associated with a transaction object1607 is a wire transfer, the classification microservice 1670 maydetermine that the wire transfer was delayed and that a payment deadlinewill be missed. The classification microservice 1670 may then determinean alternative workflow that may process the transaction object 1607 ina timely manner such that the payment deadline is not missed.

FIG. 17 depicts a flowchart illustrating an example method 1700 to trainmachine-learning models for use in a transaction exchange platform, suchas transaction exchange platform 320. Method 1700 may be performed byany suitable computing device and/or combination of computing devices,referred to as the system implementing method 1700.

At step 1710, the system may train the one or more machine-learningmodels based on a plurality of previously processed transaction objects.Each of the plurality of previously processed transaction objects maycomprise a transaction score. For example, the one or moremachine-learning models may comprise a plurality of parametersassociated with various aspects of the transaction metadata and/ortransaction details of the transaction objects. The transaction scorefor the transaction objects may be associated with the probability ofthe transaction being successfully processed using a particularworkflow. Further, the transaction score may be associated with acost-effectiveness of processing the transaction object. Training theone or more machine-learning models may comprise adjusting the weightingof the plurality of parameters such that parameters that make a greatercontribution to increasing the transaction score are weighted moreheavily than parameters that make a lesser contribution to increasingthe transaction score.

At step 1720, the system may divide a plurality of previously processedtransaction objects into a plurality of transaction clusterscorresponding to different transaction types. For example, the systemmay use one or more clustering techniques (e.g., k-means clustering,expectation maximization clustering, mean-shift clustering, etc.) tocluster previously processed transaction objects into a clusterincluding transactions that were processed using wire transfers andanother cluster including transactions that were processed using ACH.

At step 1730, the system may train the one or more machine-learningmodels using different sets of the plurality of transaction clusters.For example, the system may train the one or more machine-learningmodels using clusters associated with different transaction types and/orworkflows. By using clusters of different transaction types, the systemmay leverage associations between clusters of different transactiontypes to more effectively determine whether a transaction objectincludes information that could be used to process the transactionobject using an alternative workflow.

At step 1740, the classification microservice (e.g., the classificationmicroservice 1670, classification microservice 1820, or classificationmicroservice 1920) can send one or more requests for feedback to one ormore clients (e.g., a random sampling of the one or more clients)associated with previously processed transaction objects. For example,the classification microservice may send one or more requests forfeedback to the computing systems of one or more clients (e.g.,enterprise services and users 350). The one or more requests forfeedback may request a client rating of the costs, transaction speed,and/or transaction security associated with previously processedtransaction objects.

At step 1750, in response to receiving the feedback from the one or moreclients, the system can train one or more machine-learning models todetermine whether a transaction object can be processed via analternative workflow based on the feedback. For example, the feedbackreceived from the one or more clients may indicate that certain aspectsof the transaction (e.g., security) should be weighted more heavily thanother aspects of the transaction (e.g., cost) for certain types oftransaction objects. As a result, the weighting of the plurality ofparameters of the one or more machine-learning models can be accordinglyadjusted to reflect the feedback of the one or more clients.

Classification microservice 1670 may be configured to listen to and/orwatch the SDP to identify and retrieve transaction objects that meetcertain criteria. For example, the classification microservice 1670 mayretrieve the transaction object 1607 from the SDP 325 based on a currentworkflow stage of the transaction object 1607. Additionally oralternatively, the classification microservice 1670 may retrievetransaction object from the SDP 325 based on a determination thatprocessing of the transaction object 1607 corresponding to the workflow(e.g., the ACH workflow) did not complete successfully. Based ontransaction details associated with the transaction object 1607, theclassification microservice 1670 may determine whether the transactionobject 1607 comprises information that would allow the transactionobject 1607 to be processed via an alternative or second workflow (e.g.,an alternative workflow that comprises a different plurality ofprocessing steps from the plurality of processing steps that thetransaction object 1607 previously had). Further, the classificationmicroservice 1670 may send a request for approval to process thetransaction object 1607 via the alternative or secondary workflow to aclient computing device. The client computing device may be authorizedto approve the alternative or secondary workflow. The classificationmicroservice 1670 may retrieve a response to the request. If theresponse indicates that the alternative or secondary workflow is notapproved, the transaction exchange platform may continue the transactionobject according to the original workflow. However, if the responseindicates acceptance of the alternative or secondary workflow, theclassification microservice 1670 may process the transaction object 1607to indicate that the transaction object 1607 should be processedaccording to the alternative or secondary workflow. This processing mayinclude updating (e.g., changing) the workflow type of the transactionobject 1607 to indicate the alternative or secondary workflow. Once theclassification microservice 1670 has completed processing of thetransaction object 1607, the classification microservice 1670 can putthe transaction object 1607 back on the SDP 325 with an updated workflowtype and an updated current workflow stage indicating that theclassification microservice 1670 completed its processing. The updatedtransaction object 1607 may then be identified and processed by a nextmicroservice (e.g., the microservice 331) based on the workflow.

As noted above, the classification microservice 1670 may allowtransaction objects to be processed in a timely manner, for example, ifan original workflow associated with a transaction object is delayed.This ensures that processing of the transaction object will be completedin advance of payment deadlines. The classification microservice 1670may also allow for more efficient use of the transaction exchangeplatform's workflows by providing alternative workflows when particularworkflows experience high volumes. The classification microservice 1670may act in a load balancing capacity to evenly distribute transactionobjects between the different workflows.

The classification microservice may be used to classify transactionobjects as they are received by the transaction exchange platform.Transaction objects may be re-classified and/or re-routed to alternativeor secondary workflows. FIG. 18 depicts a flowchart illustrating anexample method 1800 to determine alternative or secondary workflows fora transaction object. Method 1800 may be performed by any suitablecomputing device and/or combination of computing devices, referred to asthe system implementing method 1800.

At step 1810, the system (e.g., the transaction exchange platform) mayreceive a transaction object. The transaction object may correspond to atransaction. Further, the transaction object may comprise transactiondetails and/or transaction metadata. The transaction metadata maycomprise an indication of a workflow corresponding to a transaction typeof the transaction object. The workflow corresponding to the transactiontype may comprise a first plurality of processing steps to process thetransaction and add it to the streaming data platform of a transactionexchange platform. The transaction object may be received from atransaction origination source such as origination source 303, and maybe received via an enterprise intermediary service, such as enterprisetransaction intermediary service 305. The transaction object may bereceived via one or more APIs of the transaction exchange platform, suchas APIs 311 and 313 of transaction exchange platform 320. Thetransaction object may be added to the SDP in an initialization stage,which may be implemented through setting a current workflow stage of thetransaction object's transaction metadata to an initialization value.The initialization stage may be separate from a first workflow stageassociated with a microservice of the workflow, or could be the same asthe first workflow stage. Objects in the initialization stage may besubject to various system processes on the transaction exchangeplatform, such as format or other verifications, standardization,snapshots, and the like. If the initialization stage is separate from afirst workflow stage of the workflow, the transaction object may beupdated to have the first workflow stage once initialization processingis completed.

The transaction object, on the SDP, may be subject to processing by oneor more microservices including classification microservice 1820 andmicroservice 1830. While FIG. 18 shows one instance of microservice1830, it will be appreciated that the transaction exchange platform maycomprise a plurality of microservices for processing a transactionobject. Classification microservice 1820 and the microservice 1830 maybe configured to listen to and/or watch the SDP for transactions in afirst workflow stage. Further, the classification microservice 1820and/or the microservice 1830 may be configured to listen to and/or watchtransactions of the streaming data platform (SDP) that have transactionmetadata indicating that the transactions are in a current workflowstage corresponding to the individual microservice. As discussed abovewith respect to FIG. 4 , the system may automatically configure themicroservices based on a DAG structure that logically defines the stepsof the workflow and their relationships.

At step 1822, the classification microservice 1820 may determine, basedon the transaction details associated with the transaction object,whether the transaction object comprises information that would allowthe transaction object to be processed via an alternative workflow. Thealternative workflow may correspond to an alternative transaction typeand comprise a second plurality of processing steps to process thetransaction differently from the first plurality of processing steps.The classification microservice 1820 may use one or moremachine-learning models. Additionally or alternatively, theclassification microservice 1820 may use one or more machine learningcollector agents to gather information about transaction objects for usein optimizing performance of the transaction exchange platform byre-classifying transaction objects to alternative (e.g., different)workflows. Further, the classification microservice 1820 may use the oneor more machine-learning models to determine whether the transactionobject comprises information that would allow the transaction object tobe processed via an alternative workflow. For example, theclassification microservice 1820 may include one or moremachine-learning models that are configured and/or trained to receive aninput comprising the transaction object, perform operations on theinput, and generate output including a determination of whether thetransaction object comprises information that would allow thetransaction to be processed via an alternative workflow.

In some embodiments, the classification microservice 1820 may use one ormore rules to evaluate the transaction object and determine whether thetransaction object comprises information that would allow thetransaction to be processed via an alternative workflow. For example,the one or more rules could include a rule that if the transactionmetadata includes certain information (e.g., payment accountinformation) associated with the alternative workflow, that thetransaction object can be processed via the alternative workflow.

The determination that the transaction object can be processed via analternative workflow may be based on a payment value of the transaction,a deadline for the transaction (e.g., a lower probability of missing adeadline via the alternative workflow may weigh in favor of determiningthat the transaction object can be processed via the alternativeworkflow), a security level of the transaction (e.g., the alternativeworkflow having a higher security level may weigh in favor ofdetermining that the transaction object can be processed via thealternative workflow), and/or a cost of the transaction (e.g., a lowercost associated with the alternative workflow may weigh in favor ofdetermining that the transaction object can be processed via analternative workflow).

Furthermore, the determination that the transaction object can beprocessed via an alternative workflow may comprise determining atransaction deadline for the transaction, and/or determining, using oneor more machine-learning models, an estimated time of completion for thetransaction. For example, the classification microservice 1820 mayextract the transaction deadline from the transaction metadata and maydetermine if the transaction can be processed by the deadline using thecurrent workflow and if not, whether there is an alternative workflowthat can process the transaction by the deadline. By way of furtherexample, the classification microservice 1820 may use one or moremachine-learning models to determine an estimated time of completion forthe transaction and can determine that an alternative workflow can beused if the estimated time of completion does not meet a deadline forthe transaction.

The classification microservice 1820 may use one or moremachine-learning models to determine a first transaction score forprocessing the transaction object according to the workflowcorresponding to the transaction type. The first transaction score maybe based on transaction score criteria comprising a probability that thetransaction may be successfully completed, a payment value of thetransaction, a probability of meeting a deadline for the transaction, acost to complete the transaction, a cost-effectiveness of completing thetransaction, and/or a security level associated with the transaction.The score may be a numerical value in which a higher numerical valueindicates a higher score.

The classification microservice 1820 may use one or moremachine-learning models to determine a second transaction score forprocessing the transaction object according to the alternative workflowcorresponding to the transaction type. The second transaction score maybe based on any of the transaction score criteria used to determine thefirst transaction score. The classification microservice 1820 maycompare the first transaction score to the second transaction score todetermine the score that is associated with a more cost-effectiveapproach to processing the transaction object. Further, thedetermination that the transaction object can be processed via analternative workflow may be based on an indication (e.g., an indicationassociated with the second transaction score being higher than the firsttransaction score) that the second transaction score represents a morecost-effective approach than the first transaction score.

At step 1824, the system may send, based on a determination that thetransaction object can be processed via an alternative workflow, arequest for approval to process the transaction object via thealternative workflow. The system request may be sent to one or moreremote computing devices operated by one or more entities that areauthorized to approve processing of the transaction object via thealternative workflow. For example, if the initial workflow wasassociated with a workflow using ACH payments a request for approval tochange to an alternative workflow associated with use of a cashier checkmay be sent to an appropriate entity that has the authority to approvethe request. The system may receive a response to the request. If theresponse indicates that the alternative or secondary workflow is notapproved, the system may process the transaction object according to theoriginal workflow. However, if the response indicates acceptance of thealternative or secondary workflow, the classification microservice 1830may process the transaction object (e.g., transaction object 1607 inFIG. 16 ) to indicate that the transaction object should be processedaccording to the alternative or secondary workflow.

At step 1826, in response to receiving approval, the classificationmicroservice 1820 may change the indication of the workflow to thealternative workflow. For example, the classification microservice maychange the indication that a workflow corresponded to an ACH transactiontype to an indication that the workflow (the alternative workflow)corresponds to a transaction type in which a cashier's check is used.That is, the classification microservice 1820 may update the workflowtype of a transaction object to indicate the alternative workflow.

At step 1828, the classification microservice 1820 may add thetransaction object to the streaming data platform. For example, afterremoving the transaction object from the SDP to perform operations(e.g., classifying the transaction object) on the transaction object,the classification microservice may add (return) the transaction objectto the SDP with the updated workflow type.

At step 1832, a microservice 1830 may retrieve a plurality oftransaction objects. The plurality of transaction objects may comprisethe transaction object. As part of retrieving the plurality oftransaction objects, the microservice 1830 may listen to and/or watchthe SDP for transactions having a particular workflow type(corresponding to a transaction type and/or transaction details) andhaving a first workflow stage within that workflow corresponding tomicroservice 1830. The microservice 1830 may identify transactionobjects that have a current workflow stage value that matches the firstworkflow stage criteria associated with the microservice 1830.Identification of matching transactions may be based on transactionmetadata indicating a type of workflow, a current workflow stage, and/orother information associated with the workflow.

At step 1834, the microservice 1830 may process the transaction object.Processing of the transaction objects may be based on a determinationthat a current workflow stage matches a first workflow stage associatedwith the microservice 1830. Processing a transaction object may include:reviewing, assessing, analyzing, updating, adding to, removing, and/orany other suitable processing of the transaction data, addenda data,and/or transaction metadata associated with the transaction object.After processing is complete, the microservice 1830 may update thecurrent workflow stage of the transaction object and add the transactionobject, with the updated workflow stage, to the SDP for furtherprocessing.

At step 1840, the system may determine whether the current workflowstage of the transaction object (and/or the workflow tracking data)indicates that the transaction object has completed processing. Forexample, the system may assess whether the current workflow stageinformation of the transaction object indicates completion of a seriesof steps that satisfy the criteria of the alternative workflowassociated with the transaction object.

When the current workflow stage of the transaction object has beendetermined to have met the requisite steps of the alternative workflow,the process may proceed to step 1842, the completed, approvedtransaction may be output to a public SDP for access by downstreamsystems and users. That is, the transaction object may be removed fromthe SDP of the transaction exchange platform. The transaction object andan indication that the transaction object has completed the processingcorresponding to the alternative workflow may be outputted to adownstream system. For example, the transaction object may be updatedwith an indication that it completed the workflow and is approved, andmay be placed on a public SDP, such as SDP 340, that is accessible toenterprise systems and users.

If the system determines that the alternative workflow is not complete,the process may proceed to step 1844 where the transaction objectremains on the SDP to be retrieved by another microservice for furtherprocessing.

The process described above improves the performance of the transactionexchange platform by distributing transaction objects evenly amongstdifferent workflows. The classification microservice described hereinmay more efficiently use the transaction exchange platform's workflowsby providing alternative workflows when particular workflows experiencehigh volumes. In this way, the classification microservice balances theload of the transaction exchange platform to evenly distributetransaction objects amongst different workflows. This ensures thattransaction objects are processed in advanced of due dates and/ordeadlines.

The classification microservice may also be used to classify (e.g.,re-classify) transaction objects if processing according to the primary(e.g., original) workflow fails. FIG. 19 depicts a flowchartillustrating an example method 1900 to determine alternative orsecondary workflows for a transaction object. Method 1900 may beperformed by any suitable computing device and/or combination ofcomputing devices, referred to as the system implementing method 1900.

At step 1910, the system (e.g., a transaction exchange platform) maydetermine that processing of a transaction object according to a firstworkflow, corresponding to a transaction type of the transaction object,did not complete successfully. Determining transaction objects that didnot complete processing successfully may include a microservice, such asthe watchdog microservice described above or the classificationmicroservice described herein, listening to or watching the SDP todetermine which transactions have not completed processing. In thisregard, the transaction objects that are still pending after a deadlinefor completion of the transaction has passed may be flagged as nothaving processing completed successfully. Additionally or alternatively,transaction object that are stalled in a workflow stage for apredetermined amount of time may be deemed to have not completedprocessing successfully.

At step 1922, the classification microservice 1920 may determine, basedon the transaction details associated with the transaction object,whether the transaction object comprises information that would allowthe transaction object to be processed via a second workflow. The secondworkflow may correspond to an alternative transaction type and maycomprise a plurality of processing steps to process the transactiondifferently from the first plurality of processing steps. For example,the classification microservice 1920 may use one or moremachine-learning models to process the transaction object and determinewhether a more efficient (e.g., cost-effective or speedier) secondworkflow may be used instead of the first workflow.

Determining whether the transaction object comprises information thatwould allow the transaction to be processed via the second workflow maycomprise determining a first transaction cost associated with completingthe transaction using the first workflow. For example, theclassification microservice 1920 may determine a first transaction cost(e.g., transaction fees associated with processing the transaction usinga wire transfer) associated with completing the transaction using thefirst workflow. Further, the classification microservice 1920 may useone or more machine-learning models to determine a second transactioncost for processing the transaction object according to the secondworkflow. For example, the classification microservice 1920 maydetermine a second transaction cost (e.g., transaction fees associatedwith processing the transaction using ACH) associated with completingthe transaction using the second workflow. The determination that thetransaction object can be processed via the second workflow may be basedon an indication that the second transaction cost represents a morecost-effective approach than the first transaction cost (e.g., using ACHfor the transaction is less expensive than using a wire transfer).

The first transaction cost and/or the second transaction cost maycomprise at least one of payor transaction costs, payee transactioncosts, and/or processing entity transaction costs. Further, the firsttransaction cost and/or the second transaction cost may include aweighted cost comprising a combination of the payor transaction costs,payee transaction costs, and/or processing entity transaction costs.Further, the first transaction cost and/or the second transaction costmay comprise late fees associated with untimely completion of thetransaction processing. Late fees may be included in the firsttransaction cost and/or the second transaction cost irrespective if thetransaction has been predicted (e.g., estimated by the one or moremachine-learning models) to miss a deadline that would result in latefees.

Determining whether the transaction object comprises information thatwould allow the transaction to be processed via the second workflow maycomprise determining, by the classification microservice 1920, based ontransaction metadata associated with the transaction object, a firsttransaction speed associated with processing the transaction accordingto the first workflow. For example, the classification microservice 1920may determine the first transaction speed based on use of historicalinformation associated with the transaction details and/or transactiontype of the first workflow. By way of further example, theclassification microservice 1920 may determine the first transactionspeed based on use of one or more machine-learning models that have beenconfigured and/or trained to estimate transaction speed based in part onthe transaction details and/or transaction type associated with thefirst workflow.

Further, the classification microservice 1920 may determine, based ontransaction metadata associated with the transaction object, a secondtransaction speed associated with processing the transaction accordingto the second workflow. For example, the classification microservice1920 may determine the second transaction speed based on use ofhistorical information associated with the transaction details and/ortransaction type of the second workflow. By way of further example, theclassification microservice 1920 may determine the second transactionspeed based on use of one or more machine-learning models that have beenconfigured and/or trained to estimate transaction speed based on thetransaction details and/or transaction type associated with the secondworkflow. The determination that the transaction object can be processedvia the second workflow may be based on the second transaction speedbeing faster than the first transaction speed.

Determining whether the transaction object comprises information thatwould allow the transaction to be processed via the second workflow maycomprise determining, by the classification microservice 1920, based ontransaction metadata associated with the transaction object, a firstsecurity level associated with processing the transaction according tothe first workflow. By way of further example, the classificationmicroservice 1920 may determine the first security level based on use ofone or more machine-learning models that have been configured and/ortrained to estimate security level based in part on the transactiondetails and/or transaction type associated with the first workflow. Theestimated security level may be based in part on machine-learning modelsthat were configured and/or trained using historical informationassociated with the security levels of different workflows (e.g.,security levels based on how often the security of certain workflows iscompromised).

Further, the classification microservice 1920 may determine, based ontransaction metadata associated with the transaction object, a secondsecurity level associated with processing the transaction according tothe second workflow. For example, the classification microservice 1920may determine the second security level based on use of one or moremachine-learning models that have been configured and/or trained toestimate security level based on the transaction details and/ortransaction type associated with the second workflow. Further, thesecurity levels of the first workflow and/or the second workflow may beassociated with the level of encryption and/or security protocol used toprocess the transaction via the first workflow and/or second workflow.The determination that the transaction object can be processed via thesecond workflow may be based on the second security level being greaterthan the first security level.

Determining whether the transaction object comprises information thatwould allow the transaction to be processed via the second workflow maycomprise determining, by the classification microservice 1920, based ontransaction metadata associated with the transaction object, a firstcompletion probability associated with processing the transactionaccording to the first workflow. The classification microservice 1920may determine the first completion probability based on use ofhistorical information associated with the transaction details and/ortransaction type of the first workflow. For example, previoustransactions using certain workflows may be associated with a highercompletion probability than transactions using other types of workflows.By way of further example, the classification microservice 1920 maydetermine the first completion probability based on use of one or moremachine-learning models that have been configured and/or trained toestimate completion probability based in part on the transaction detailsand/or transaction type associated with the first workflow.

Further, the classification microservice 1920 may determine, based ontransaction metadata associated with the transaction object, a secondcompletion probability associated with processing the transactionaccording to the second workflow. For example, the classificationmicroservice 1920 may determine the second completion probability basedon use of one or more machine-learning models that have been configuredand/or trained to estimate completion probability based on thetransaction details and/or transaction type associated with the secondworkflow. The determination that the transaction object can be processedvia the second workflow may be based on the second completionprobability being greater than the first completion probability.

Determining whether the transaction object comprises information thatwould allow the transaction to be processed via the second workflow maycomprise determining, by the classification microservice 1920, based ontransaction metadata associated with the transaction object, a firstscalability associated with processing the transaction according to thefirst workflow. By way of example, the classification microservice 1920may determine the first scalability based on use of one or moremachine-learning models that have been configured and/or trained toestimate scalability based in part on the transaction details and/ortransaction type associated with the first workflow. Further, theclassification microservice 1920 may determine, based on transactionmetadata associated with the transaction object, a second scalabilityassociated with processing the transaction according to the secondworkflow. For example, the classification microservice 1920 maydetermine the second scalability based on use of one or moremachine-learning models that have been configured and/or trained toestimate scalability based on the transaction details and/or transactiontype associated with the second workflow. The determination that thetransaction object can be processed via the second workflow may be basedon the second scalability being greater than the first scalability.Greater scalability may result in more efficient use of computationalresources when large numbers of transactions are being processed.

Determining whether the transaction object comprises information thatwould allow the transaction to be processed via the second workflow maybe based on a determination that the second workflow is at least asefficient as the first workflow. The classification microservice 1920may determine respective efficiencies for the first workflow and secondworkflow based on a determination of the lowest transaction cost thatmaximizes some combination of factors comprising transaction speed,security level, completion probability, and/or scalability.

Determining whether the transaction object comprises information thatwould allow the transaction to be processed via the second workflow maybe based on the second workflow completing processing of the transactionbefore a transaction deadline of the transaction. The classificationmicroservice 1920 may use historical information and/or the one or moremachine-learning models to predict whether the second workflow can beused to complete the transaction before the deadline. If the secondworkflow is predicted to be able to complete processing of thetransaction before the deadline and/or before the first workflow, theclassification microservice may determine that the second workflow maybe used to complete processing of the transaction before the transactiondeadline.

At step 1924, the system may send a request for approval to process thetransaction object via the second workflow. Sending the request forapproval may be based on and/or contingent on a determination that thetransaction object can be processed via the second workflow, a requestfor approval to process the transaction object via the second workflow.In particular, the system may send a request to one or more remotecomputing devices operated by one or more entities that are authorizedto approve processing of the transaction object via the second workflow.For example, if the first workflow was associated with a wire transfertransaction a request for approval to change to a second workflowassociated with use of a cashier's check may be sent to an appropriateentity that has the authority to approve the request. In response to therequest, the classification microservice 1920 may receive a response.The response may indicate that the alternative or secondary workflow isnot approved. Accordingly, the transaction object may be processed tothe first workflow. Alternatively, the response may indicate acceptanceof the alternative or secondary workflow. The classificationmicroservice 1930 may then process the transaction object (e.g.,transaction object 1607 in FIG. 16 ) to indicate that the transactionobject should be processed according to the alternative or secondaryworkflow.

At step 1926, the system may determine whether approval to process thetransaction object via the second workflow was received. Based onreceiving approval to process the transaction object via the secondworkflow, the classification microservice 1920 may, at step 1928, putback or add the transaction object to the streaming data platform withan indication of the second workflow. For example, after removing thetransaction object from the SDP to perform operations (e.g., classifyingthe transaction type and/or transaction details associated with thetransaction object) on the transaction object and receiving approvalfrom the client associated with the transaction object, theclassification microservice may add (put back) the transaction object tothe SDP with the updated workflow type (e.g., the workflow typecorresponding to the second workflow).

If approval to process the transaction object via the second workflowwas not received, the system may return to step 1924 and send anotherrequest for approval to process the transaction object via the secondworkflow.

At step 1932, the microservice 1930 may retrieve a plurality oftransaction objects. The plurality of transaction objects may comprisethe transaction object. As part of retrieving the plurality oftransaction objects, the microservice 1930 may listen to and/or watchthe SDP for transactions that have a particular workflow type(corresponding to a transaction type and/or transaction details) andhaving a first workflow stage within that workflow corresponding tomicroservice 1930.

At step 1934, the microservice 1930 may determine whether thetransaction object has a current workflow stage that matches the firstworkflow stage criteria associated with the microservice 1930.Determination of matching transactions may be based on transactionmetadata indicating a type of workflow, a current workflow stage, and/orother information associated with the workflow. Based on a determinationthat a current workflow stage of the transaction object matches a firstworkflow stage associated with the microservice, the microservice 1930may, at step 1936, process the transaction objects it retrieved from theSDP based on a determination that a current workflow stage of thetransaction object matches a first workflow stage associated withmicroservice 1930. Processing a transaction object may include:reviewing, assessing, analyzing, updating, adding to, removing, and/orany other suitable processing of the transaction data, addenda data,and/or transaction metadata associated with the transaction object.After processing of the transaction object is complete, the microservice1830 may update the current workflow stage of the transaction object andadd the transaction object, with the updated workflow stage, to the SDP.After the transaction object has been added to the SDP, the transactionobject may undergo further processing.

Based on a determination that a current workflow stage of thetransaction object does not match a first workflow stage associated withthe microservice, the microservice 1930 may further analyze thetransaction object to determine whether the current workflow stagematches the first workflow stage criteria or retrieve the transactionobject again at step 1932.

At step 1940, the system may determine whether the current workflowstage of the transaction object (and/or the workflow tracking data)indicates that the transaction object has completed processingcorresponding to the second workflow. For example, the system maydetermine whether the current workflow stage information of thetransaction object indicates the completion of a set of steps oroperations that satisfy the criteria of the workflow associated with thetransaction type of the transaction object. When the current workflowstage of the transaction object has been determined to have satisfiedthe criteria of the workflow, the system may, to step 1942, remove thetransaction object from the SDP and output, to a downstream system, thetransaction object with an indication that the transaction that thetransaction object has completed processing corresponding to the secondworkflow. For example, the system may update the transaction object withan indication that the transaction object completed the workflow, isapproved, and may be placed on a public SDP, such as SDP 340, that isaccessible to enterprise systems and users. Further, the completed,approved transaction object may be output to a public SDP for access bydownstream systems and users which may perform additional operations onthe transaction object.

If the system determines that the alternative workflow is not complete,the process may proceed to step 1944 where the transaction objectremains on the SDP or is returned to the SDP, where the transactionobject can be retrieved by another microservice for further processing.Processing may continue in this manner until the workflow has beencompleted.

The transaction exchange platform may be improved using the techniquesdescribed herein by distributing the processing of transaction objectsamong different workflows. This would avoid bottlenecks for certainworkflows and makes more efficient use of the transaction exchangeplatforms resources. This would avoid certain workflows from beingoverloaded. Accordingly, the classification microservice may helpbalance the load of the transaction exchange platform, which would helpin completing the processing of transaction objects ahead of datesand/or deadlines.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

What is claimed is:
 1. A computer-implemented method comprising:determining, by a streaming data platform, that processing of atransaction object according to a first workflow, corresponding to atransaction type of the transaction object, did not completesuccessfully; determining, by a classification microservice and based ontransaction details associated with the transaction object, whether thetransaction object comprises information that would allow thetransaction object to be processed via a second workflow, wherein thesecond workflow corresponds to an alternative transaction type andcomprises a plurality of processing steps to process a transactiondifferent from a plurality of processing steps associated with the firstworkflow; sending, based on a determination that the transaction objectcan be processed via the second workflow, a request for approval toprocess the transaction object via the second workflow; adding, by theclassification microservice and based on receiving approval to processthe transaction object via the second workflow, the transaction objectto the streaming data platform with an indication of the secondworkflow; retrieving, by a first microservice, a plurality oftransaction objects, wherein the plurality of transaction objectscomprises the transaction object; processing, by the first microserviceand based on a determination that a current workflow stage of thetransaction object matches a first workflow stage associated with firstmicroservice, the transaction object; determining that the currentworkflow stage of the transaction object indicates that the transactionobject has completed processing corresponding to the second workflow;and removing the transaction object from the streaming data platform andoutputting the transaction object with an indication that thetransaction object has completed the processing corresponding to thesecond workflow to a downstream system.
 2. The computer-implementedmethod of claim 1, wherein the determining, by the classificationmicroservice, whether the transaction object comprises information thatwould allow the transaction object to be processed via the secondworkflow further comprises: determining, by the classificationmicroservice, a first transaction cost associated with completing thetransaction using the first workflow; and determining, by theclassification microservice and using one or more machine-learningmodels, a second transaction cost for processing the transaction objectaccording to the second workflow, wherein the determination that thetransaction object can be processed via the second workflow is furtherbased on an indication that the second transaction cost represents amore cost-effective approach than the first transaction cost.
 3. Thecomputer-implemented method of claim 2, wherein the first transactioncost and the second transaction cost comprise at least one of: payortransaction costs, payee transaction costs, or processing entitytransaction costs.
 4. The computer-implemented method of claim 2,wherein the first transaction cost and the second transaction costcomprise late fees associated with untimely completion of thetransaction processing.
 5. The computer-implemented method of claim 1,wherein the determining, by the classification microservice, whether thetransaction object comprises information that would allow thetransaction object to be processed via the second workflow furthercomprises: determining, by the classification microservice, based ontransaction metadata associated with the transaction object, a firsttransaction speed associated with processing the transaction accordingto the first workflow; and determining, by the classificationmicroservice, based on one or more machine-learning models, a secondtransaction speed associated with processing the transaction accordingto the second workflow, wherein the determination that the transactionobject can be processed via the second workflow is further based on thesecond transaction speed being faster than the first transaction speed.6. The computer-implemented method of claim 1, wherein the determining,by the classification microservice, whether the transaction objectcomprises information that would allow the transaction object to beprocessed via the second workflow further comprises: determining, by theclassification microservice, a first security level associated withprocessing the transaction according to the first workflow; anddetermining, by the classification microservice and based on one or moremachine-learning models, a second security level associated withprocessing the transaction according to the second workflow, wherein thedetermination that the transaction object can be processed via thesecond workflow is further based on the second workflow being at leastas secure as the first workflow.
 7. The computer-implemented method ofclaim 1, wherein the determining, by the classification microservice,whether the transaction object comprises information that would allowthe transaction object to be processed via the second workflow furthercomprises: determining, by the classification microservice and based ontransaction metadata, a first completion probability associated withprocessing the transaction according to the first workflow; anddetermining, by the classification microservice and based on one or moremachine-learning models analyzing the transaction metadata, a secondcompletion probability associated with processing the transactionaccording to the second workflow, wherein the determination that thetransaction object can be processed via the second workflow is furtherbased on the second completion probability being greater than or equalto the first completion probability.
 8. The computer-implemented methodof claim 1, wherein the determining, by the classification microservice,whether the transaction object comprises information that would allowthe transaction object to be processed via the second workflow furthercomprises: determining, by the classification microservice and based ontransaction metadata, a first scalability associated with processing thetransaction according to the first workflow; and determining, by theclassification microservice and based on one or more machine-learningmodels analyzing the transaction metadata, a second scalabilityassociated with processing the transaction according to the secondworkflow, wherein the determination that the transaction object can beprocessed via the second workflow is further based on the secondscalability being greater than or equal to the first scalability.
 9. Thecomputer-implemented method of claim 1, wherein the determining, by theclassification microservice, whether the transaction object comprisesinformation that would allow the transaction object to be processed viathe second workflow is further based on a determination that the secondworkflow is at least as efficient as the first workflow.
 10. Thecomputer-implemented method of claim 1, wherein the determining, by theclassification microservice, whether the transaction object comprisesinformation that would allow the transaction object to be processed viathe second workflow is further based on the second workflow completingprocessing of the transaction before a transaction deadline of thetransaction.
 11. One or more non-transitory computer readable mediacomprising instructions that, when executed by at least one processor,cause a computing device to perform operations comprising: determiningthat processing of a transaction object according to a first workflow,corresponding to a transaction type of the transaction object, did notcomplete successfully; determining, by a classification microservice andbased on transaction details associated with the transaction object,whether the transaction object comprises information that would allowthe transaction object to be processed via a second workflow, whereinthe second workflow corresponds to an alternative transaction type andcomprises a plurality of processing steps to process a transactiondifferent from a plurality of processing steps associated with the firstworkflow; sending, based on a determination that the transaction objectcan be processed via the second workflow, a request for approval toprocess the transaction object via the second workflow; adding, by theclassification microservice and based on receiving approval to processthe transaction object via the second workflow, the transaction objectto a streaming data platform with an indication of the second workflow;retrieving, by a first microservice, a plurality of transaction objects,wherein the plurality of transaction objects comprises the transactionobject; processing, by the first microservice and based on adetermination that a current workflow stage of the transaction objectmatches a first workflow stage associated with first microservice, thetransaction object; determining that the current workflow stage of thetransaction object indicates that the transaction object has completedprocessing corresponding to the second workflow; and removing thetransaction object from the streaming data platform and outputting thetransaction object with an indication that the transaction object hascompleted the processing corresponding to the second workflow to adownstream system.
 12. The one or more non-transitory computer readablemedia of claim 11, wherein the determining, by the classificationmicroservice, whether the transaction object comprises information thatwould allow the transaction object to be processed via the secondworkflow further comprises: determining, by the classificationmicroservice, a first transaction cost associated with completing thetransaction using the first workflow; and determining, by theclassification microservice and using one or more machine-learningmodels, a second transaction cost for processing the transaction objectaccording to the second workflow, wherein the determination that thetransaction object can be processed via the second workflow is furtherbased on an indication that the second transaction cost represents amore cost-effective approach than the first transaction cost.
 13. Theone or more non-transitory computer readable media of claim 12, whereinthe first transaction cost and the second transaction cost comprise atleast one of: payor transaction costs, payee transaction costs, orprocessing entity transaction costs.
 14. The one or more non-transitorycomputer readable media of claim 12, wherein the first transaction costand the second transaction cost comprise late fees associated withuntimely completion of the transaction processing.
 15. The one or morenon-transitory computer readable media of claim 11, wherein thedetermining, by the classification microservice, whether the transactionobject comprises information that would allow the transaction object tobe processed via the second workflow further comprises: determining, bythe classification microservice, based on transaction metadataassociated with the transaction object, a first transaction speedassociated with processing the transaction according to the firstworkflow; and determining, by the classification microservice, based onone or more machine-learning models, a second transaction speedassociated with processing the transaction according to the secondworkflow, wherein the determination that the transaction object can beprocessed via the second workflow is further based the secondtransaction speed being faster than the first transaction speed.
 16. Atransaction exchange platform comprising: a streaming data platform; aplurality of microservices comprising at least a classificationmicroservice and a first microservice, wherein the classificationmicroservice and the first microservice are automatically configured towatch for transactions on the streaming data platform in correspondingworkflow stages based on a plurality of workflows corresponding to aplurality of transaction types; at least one processor; and memorystoring instructions that, when executed by the at least one processor,cause the transaction exchange platform to: determine, by the streamingdata platform, that processing of a transaction object according to afirst workflow, corresponding to a transaction type of the transactionobject, did not complete successfully; determine, by the classificationmicroservice and based on transaction details associated with atransaction object, whether the transaction object comprises informationthat would allow the transaction object to be processed via a secondworkflow, wherein the second workflow corresponds to an alternativetransaction type and comprises a plurality of processing steps toprocess a transaction different from a plurality of processing stepsassociated with the first workflow; send, based on a determination thatthe transaction object can be processed via the second workflow, arequest for approval to process the transaction object via the secondworkflow; add, by the classification microservice and based on receivingapproval to process the transaction object via the second workflow, thetransaction object to the streaming data platform with an indication ofthe second workflow; retrieve, by the first microservice, a plurality oftransaction objects, wherein the plurality of transaction objectscomprises the transaction object; process, by the first microservice andbased on a determination that a current workflow stage of thetransaction object matches a first workflow stage associated with firstmicroservice, the transaction object; determine that the currentworkflow stage of the transaction object indicates that the transactionobject has completed processing corresponding to the second workflow;and remove the transaction object from the streaming data platform andoutput the transaction object with an indication that the transactionobject has completed the processing corresponding to the second workflowto a downstream system.
 17. The transaction exchange platform of claim16, wherein the instructions, when executed by the at least oneprocessor, further cause the transaction exchange platform to: determinea first transaction cost associated with completing the transactionusing the first workflow; and determine, using one or moremachine-learning models, a second transaction cost for processing thetransaction object according to the second workflow, wherein thedetermination that the transaction object can be processed via thesecond workflow is further based on an indication that the secondtransaction cost represents a more cost-effective approach than thefirst transaction cost.
 18. The transaction exchange platform of claim17, wherein the first transaction cost and the second transaction costcomprise at least one of: payor transaction costs, payee transactioncosts, or processing entity transaction costs.
 19. The transactionexchange platform of claim 17, wherein the first transaction cost andthe second transaction cost comprise late fees associated with untimelycompletion of the transaction processing.
 20. The transaction exchangeplatform of claim 16, wherein the instructions to determine whether thetransaction object comprises information that would allow thetransaction object to be processed via the second workflow, whenexecuted by the at least one processor, further cause the transactionexchange platform to: determine, based on transaction metadataassociated with the transaction object, a first transaction speedassociated with processing the transaction according to the firstworkflow; and determine, based on one or more machine-learning models, asecond transaction speed associated with processing the transactionaccording to the second workflow, wherein the determination that thetransaction object can be processed via the second workflow is furtherbased the second transaction speed being faster than the firsttransaction speed.